From lstewart at freebsd.org Wed Apr 1 00:20:12 2009 From: lstewart at freebsd.org (Lawrence Stewart) Date: Wed Apr 1 00:20:20 2009 Subject: [SOLVED->UNSOLVED] Re: kernel panic with snd_hda "panic: Duplicate free of item 0xffffff00025f8c00 from zone 0xffffff00b697d400(1024)" (possibly an ACPI issue?) In-Reply-To: <49D0150E.8050601@room52.net> References: <49CF0754.9070907@room52.net> <49CF2B0C.7050301@FreeBSD.org> <49CF6551.4080301@room52.net> <49CF68C4.8020806@FreeBSD.org> <49D0150E.8050601@room52.net> Message-ID: <49D3159E.5000901@freebsd.org> Lawrence Stewart wrote: > Alexander Motin wrote: >> Lawrence Stewart wrote: >>> Alexander Motin wrote: >>>> I can't reproduce neither "Invalid corb size (0)" error, nor the >>>> crash in case of it. I have tried to simulate that error, but system >>>> handled it correctly. But I have INVARIANTS disabled on my system. >>>> >>>> Can you try to disable MSI? >>> >>> Setting hw.pci.enable_msix=0 and hw.pci.enable_msi=0 at the loader >>> prompt made no difference. >> >> It could also be done with hint.hdac.0.msi=0. >> >>>> Can you try to move hdac_irq_alloc() call after hdac_rirb_init() in >>>> hdac_attach()? May be interrupt shots while something is not yet >>>> initialized? >>> >>> Running with the following patch made no difference either. >>> >>> Any other ideas I could try? >> >> I have none. I haven't changed anything significant last time, except >> enabling MSI. You can try to investigate both problems: original >> "Invalid corb size (0)" and the consequent crash. As I have said, I >> can't reproduce none of them. Try to put some debug printfs inside >> hdac_get_capabilities(), may be it give some new clues. >> > > Seems to have been a red herring. I tried a couple of older kernel > revisions which made no difference. Booting into windows, the sound card > works fine. Then I booted into FreeBSD and it booted fine without the > panic, although the hda driver spewed out a heap of error messages like > this: > > Mar 30 09:50:12 lstewart-laptop kernel: hdac0: > hdac_command_send_internal: TIMEOUT numcmd=1, sent=1, received=0 > Mar 30 09:50:12 lstewart-laptop kernel: hdac0: > hdac_command_send_internal: TIMEOUT numcmd=1, sent=1, received=0 > Mar 30 09:50:12 lstewart-laptop kernel: hdac0: Codec #0 is not > responding! Probing aborted. > > repeated up to: > > Mar 30 09:50:12 lstewart-laptop kernel: hdac0: > hdac_command_send_internal: TIMEOUT numcmd=1, sent=0, received=0 > Mar 30 09:50:12 lstewart-laptop kernel: hdac0: > hdac_command_send_internal: TIMEOUT numcmd=1, sent=0, received=0 > Mar 30 09:50:12 lstewart-laptop kernel: hdac0: Codec #14 is not > responding! Probing aborted. > > Then I rebooted again and got the panic on every reboot. Weird. > > On a whim, I suspected fishy BIOS settings left over after a BIOS > upgrade so I reset all BIOS values to factory defaults and now it seems > to be working fine. There are no audio related options in the BIOS, so > not sure what was broken but something must not have been happy or must > have been left in an inconsistent state somehow. > > Sorry for not having thought of it sooner, but it looks like the case is > closed. > So... just got this panic again, for no discernible reason. Turn the laptop on and bam. Reboot and try again, same panic. So I try my previous trick and enter the BIOS screen, reset all to factory defaults, save and exit - everything is fine once again. I hadn't entered the BIOS since resetting everything to factory defaults last time which resolved the issue as noted in my previous email. So, either the BIOS is dodgy, or FreeBSD is tickling something in a bad way. I don't think I've found any evidence to implicate either theory yet. As a starting point, I poured over the kernel boot log and noticed this line: Apr 1 16:53:34 lstewart-laptop kernel: ACPI Warning (tbutils-0243): Incorrect checksum in table [ASF!] - C8, should be 5E [20070320] Could anyone enlighten me as to whether that is a cause for concern? Might make the "dodgy BIOS" theory more likely if the incorrect checksum is indeed bad. The full verbose boot log is available at: http://people.freebsd.org/~lstewart/misc/intel_debug/verbose_boot.txt Cheers, Lawrence From ccuiyyan at gmail.com Wed Apr 1 00:38:30 2009 From: ccuiyyan at gmail.com (=?GB2312?B?tN7R0mNjdWl5eWFuQHNpbmEuY29t?=) Date: Wed Apr 1 00:38:37 2009 Subject: Performance Tools in FreeBSD Message-ID: <4451ccf20904010038p64ed2540mec3249f89bb7b8c2@mail.gmail.com> Dear all: I wonder to know which kind of performance tools FreeBSD hackers use to identify scalability or performance bottlenecks. I really have a hard time in that. To identify bottlenecks in our benchmarks, i try PMC and Dtrace. However, PMC seems not to be supported in AMD Opteron CPU because i get a "invalid arguments" error when i use the command pmcstat -S instructions -O . However, "instructions, cycles,..." are documented in pmc manual. By the way, I enable the options in configuration file options HWPMC_HOOKS and device hwpmc. So i give up PMC and turn to Dtrace in BSD. Dtrace in FreeBSD can work, but the information is meaningless. Profile provider cannot be used. (When i used, the kernel goes into kdb.) Tick provider can be used (It can only work on one CPU by definition). However, when i use aggregation like "dtrace -n 'tick-10ms /arg0!=0/{@ks[probefunc] = count();}'" There are no human readable results. Only tools i can use is the stack() command. However, the results are limited. I know Dtrace is a tool in FreeBSD under development. Are there any tools recommended to do kernel profiling or callgraph effectively? (which functions take the most time) Best Wishes! Yan From army.of.root at googlemail.com Wed Apr 1 01:22:40 2009 From: army.of.root at googlemail.com (army.of.root) Date: Wed Apr 1 01:22:47 2009 Subject: New rc.d/named features for testing: auto-forwarding and wait on boot In-Reply-To: <973.1238529980@critter.freebsd.dk> References: <973.1238529980@critter.freebsd.dk> Message-ID: <49D31CA1.9080201@googlemail.com> Poul-Henning Kamp wrote: > In message <200903312004.n2VK4G9s077941@hergotha.csail.mit.edu>, Garrett Wollma > n writes: > >> I'm not sure if this is fixed in more recent versions on ntpd. (I'm >> also dubious that you'd really want to wait 3*MINPOLL for ntpd to >> figure out what's going on before you finish booting, but that's more >> an argument to have with Dave Mills.) > > I'm pretty sure everybody else than Dave Mills runs ntpdate before > they start ntpd :-) > Hi, I use ntpd_sync_on_start="YES" in my rc.conf . From gary.jennejohn at freenet.de Wed Apr 1 01:49:01 2009 From: gary.jennejohn at freenet.de (Gary Jennejohn) Date: Wed Apr 1 01:49:07 2009 Subject: Removal of GEOM_BSD, GEOM_MBR, GEOM_PC98 and GEOM_SUNLABEL In-Reply-To: <60084D1E-9F64-463A-A8E9-7A237D5C7661@mac.com> References: <95891.1238477069@critter.freebsd.dk> <20090331133132.1e191836@ernst.jennejohn.org> <20090331155542.74d89d64@ernst.jennejohn.org> <60084D1E-9F64-463A-A8E9-7A237D5C7661@mac.com> Message-ID: <20090401104856.1feb6a79@ernst.jennejohn.org> On Tue, 31 Mar 2009 09:00:55 -0700 Marcel Moolenaar wrote: > > On Mar 31, 2009, at 6:55 AM, Gary Jennejohn wrote: > >>> > >>> I have some disks which were partitioned before GEOM or gpart even > >>> existed. If this means that I can't use them any more I'll be very > >>> ticked off. > >> > >> No, the question is which GEOM class to use to parse the partition > >> table :) > >> > >> gpart is new, shiny, but with some rough edges (most of which have > >> been > >> polished by now), GEOM_xxx were the old classes. 8-CURRENT doesn't > >> use > >> the old classes but they are still there if anyone needs them. > >> > > > > Well, that would be OK then, as long as I can still _use_ the old > > classes > > after the removal of the various GEOM_XXX options. > > Why do you want to use the old classes when gpart can be used? > Because the disks were already labeled long ago and I do not want to risk blowing them away by relabeling them? I must admit that I'm not sure whether that would really be a problem since I haven't wanted to risk trying it with gpart. They may just still work. At the moment I see complaints about geometry and rawoffset. As long as the complaints remain complaints and everything still works then I won't care about the change. > BTW: it was my intention to remove the source files along with > the options. So you wouldn't be able to use the old classes. > Hmm. --- Gary Jennejohn From xkuipjiedeyt at gmail.com Wed Apr 1 01:50:46 2009 From: xkuipjiedeyt at gmail.com (XkuIPjIedEYT XkuIPjIedEYT) Date: Wed Apr 1 01:50:53 2009 Subject: How can I change the MAC address of ath0? Message-ID: <1128196a0904010150v572edbd4sb9ab080e2cd8bbb1@mail.gmail.com> I'm running the FreeBSD 8.0-CURRENT r190504. # dmesg | grep ^ath0 ath0: mem 0xf4000000-0xf400ffff irq 18 at device 11.0 on pci0 ath0: [ITHREAD] ath0: AR2413 mac 7.9 RF2413 phy 4.5 changing the MAC address directly on ath0 didn't work: # ifconfig ath0 link 00:aa:bb:cc:dd:ee ifconfig: ioctl (SIOCAIFADDR): Operation not supported by device # ifconfig ath0 ether 00:aa:bb:cc:dd:ee ifconfig: ioctl (SIOCAIFADDR): Operation not supported by device it worked when creating wlan0 with the wlanaddr option, but I can't associate to the AP if I try to change the MAC address of wlan0. Any help? From olivier at gid0.org Wed Apr 1 01:56:10 2009 From: olivier at gid0.org (Olivier SMEDTS) Date: Wed Apr 1 01:56:18 2009 Subject: Removal of GEOM_BSD, GEOM_MBR, GEOM_PC98 and GEOM_SUNLABEL In-Reply-To: <20090401104856.1feb6a79@ernst.jennejohn.org> References: <95891.1238477069@critter.freebsd.dk> <20090331133132.1e191836@ernst.jennejohn.org> <20090331155542.74d89d64@ernst.jennejohn.org> <60084D1E-9F64-463A-A8E9-7A237D5C7661@mac.com> <20090401104856.1feb6a79@ernst.jennejohn.org> Message-ID: <367b2c980904010156w48c401afo469dca8cb90926e2@mail.gmail.com> 2009/4/1 Gary Jennejohn : > On Tue, 31 Mar 2009 09:00:55 -0700 > Marcel Moolenaar wrote: > >> >> On Mar 31, 2009, at 6:55 AM, Gary Jennejohn wrote: >> >>> >> >>> I have some disks which were partitioned before GEOM or gpart even >> >>> existed. ?If this means that I can't use them any more I'll be very >> >>> ticked off. >> >> >> >> No, the question is which GEOM class to use to parse the partition >> >> table :) >> >> >> >> gpart is new, shiny, but with some rough edges (most of which have >> >> been >> >> polished by now), GEOM_xxx were the old classes. 8-CURRENT doesn't >> >> use >> >> the old classes but they are still there if anyone needs them. >> >> >> > >> > Well, that would be OK then, as long as I can still _use_ the old >> > classes >> > after the removal of the various GEOM_XXX options. >> >> Why do you want to use the old classes when gpart can be used? >> > > Because the disks were already labeled long ago and I do not want > to risk blowing them away by relabeling them? You won't have to relabel them. > I must admit that I'm not sure whether that would really be a problem > since I haven't wanted to risk trying it with gpart. ?They may just > still work. > > At the moment I see complaints about geometry and rawoffset. ?As long > as the complaints remain complaints and everything still works then I > won't care about the change. > >> BTW: it was my intention to remove the source files along with >> the options. So you wouldn't be able to use the old classes. >> > > Hmm. > > --- > Gary Jennejohn > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > -- Olivier Smedts _ ASCII ribbon campaign ( ) e-mail: olivier@gid0.org - against HTML email & vCards X www: http://www.gid0.org - against proprietary attachments / \ "Il y a seulement 10 sortes de gens dans le monde : ceux qui comprennent le binaire, et ceux qui ne le comprennent pas." From pluknet at gmail.com Wed Apr 1 01:59:16 2009 From: pluknet at gmail.com (pluknet) Date: Wed Apr 1 01:59:23 2009 Subject: How can I change the MAC address of ath0? In-Reply-To: <1128196a0904010150v572edbd4sb9ab080e2cd8bbb1@mail.gmail.com> References: <1128196a0904010150v572edbd4sb9ab080e2cd8bbb1@mail.gmail.com> Message-ID: 2009/4/1 XkuIPjIedEYT XkuIPjIedEYT : > I'm running the FreeBSD 8.0-CURRENT r190504. > > # dmesg | grep ^ath0 > ath0: mem 0xf4000000-0xf400ffff irq 18 at device 11.0 on pci0 > ath0: [ITHREAD] > ath0: AR2413 mac 7.9 RF2413 phy 4.5 > > changing the MAC address directly on ath0 didn't work: > > # ifconfig ath0 link 00:aa:bb:cc:dd:ee > ifconfig: ioctl (SIOCAIFADDR): Operation not supported by device > > # ifconfig ath0 ether 00:aa:bb:cc:dd:ee > ifconfig: ioctl (SIOCAIFADDR): Operation not supported by device It looks that something was changed in this area in r190508. -- wbr, pluknet From avatar at mmlab.cse.yzu.edu.tw Wed Apr 1 04:32:37 2009 From: avatar at mmlab.cse.yzu.edu.tw (Tai-hwa Liang) Date: Wed Apr 1 04:32:44 2009 Subject: Removal of GEOM_BSD, GEOM_MBR, GEOM_PC98 and GEOM_SUNLABEL In-Reply-To: <60084D1E-9F64-463A-A8E9-7A237D5C7661@mac.com> References: <95891.1238477069@critter.freebsd.dk> <20090331133132.1e191836@ernst.jennejohn.org> <20090331155542.74d89d64@ernst.jennejohn.org> <60084D1E-9F64-463A-A8E9-7A237D5C7661@mac.com> Message-ID: <0904011910169.29800@www.mmlab.cse.yzu.edu.tw> On Tue, 31 Mar 2009, Marcel Moolenaar wrote: > > On Mar 31, 2009, at 6:55 AM, Gary Jennejohn wrote: >>>> >>>> I have some disks which were partitioned before GEOM or gpart even >>>> existed. If this means that I can't use them any more I'll be very >>>> ticked off. >>> >>> No, the question is which GEOM class to use to parse the partition table >>> :) >>> >>> gpart is new, shiny, but with some rough edges (most of which have been >>> polished by now), GEOM_xxx were the old classes. 8-CURRENT doesn't use >>> the old classes but they are still there if anyone needs them. >>> >> >> Well, that would be OK then, as long as I can still _use_ the old classes >> after the removal of the various GEOM_XXX options. > > Why do you want to use the old classes when gpart can be used? > > BTW: it was my intention to remove the source files along with > the options. So you wouldn't be able to use the old classes. That's too bad. Since my /home is sitting on the extended partition, the OS won't boot unless the kernel is built with various GEOM_PART_ removed from i386/conf/DEFAULT plus GEOM_{BSD,MBR} added back to the kernel configuration file(ie: GENERIC kernel cvsup'ed today doesn't boot). # gpart show => 0 31250961 ad0s7c BSD (15G) 0 31250945 1 freebsd-ufs (15G) 31250945 16 - free - (8.0K) => 0 16783200 ad0s2c BSD (8.0G) 0 786432 1 freebsd-ufs (384M) 786432 4194304 2 freebsd-swap (2.0G) 4980736 393216 4 freebsd-ufs (192M) 5373952 11409248 5 freebsd-ufs (5.4G) -- Cheers, Tai-hwa Liang From bj at SerNet.DE Wed Apr 1 03:31:42 2009 From: bj at SerNet.DE (=?iso-8859-1?Q?Bj=F6rn?= JACKE) Date: Wed Apr 1 04:39:48 2009 Subject: Compiling CURRENT with XEN config fails In-Reply-To: <20090401100438.GA5039@SerNet.DE> References: <1238162602.24399.29.camel@phoenix.blechhirn.net> <20090401100438.GA5039@SerNet.DE> Message-ID: Hi, On 2009-04-01 at 12:04 +0200 Bj?rn JACKE sent off: > On 2009-03-27 at 15:03 +0100 Mister Olli sent off: > > /usr/src/sys/xen/evtchn/evtchn.c:516: error: conflicting types for 'bind_virq_to_irqhandler' > > /usr/src/sys/xen/xen_intr.h:61: error: previous declaration of 'bind_virq_to_irqhandler' was here > > /usr/src/sys/xen/evtchn/evtchn.c: In function 'bind_virq_to_irqhandler': > > /usr/src/sys/xen/evtchn/evtchn.c:523: error: 'arg' undeclared (first use in this function) > > /usr/src/sys/xen/evtchn/evtchn.c:523: error: (Each undeclared identifier is reported only once > > /usr/src/sys/xen/evtchn/evtchn.c:523: error: for each function it appears in.) > > *** Error code 1 > > the attached patch should fix this one. Can someone review that please? there are a whole bunch of other compile bugs that had been introduced with r189699. Doug, can you please try to do a xen kernel compile with and without SMP support and take a look at the issues? Thanks... Bj?rn -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20090401/39d5f364/attachment.pgp From bj at SerNet.DE Wed Apr 1 03:31:42 2009 From: bj at SerNet.DE (=?iso-8859-1?Q?Bj=F6rn?= JACKE) Date: Wed Apr 1 04:40:40 2009 Subject: Compiling CURRENT with XEN config fails In-Reply-To: <1238162602.24399.29.camel@phoenix.blechhirn.net> References: <1238162602.24399.29.camel@phoenix.blechhirn.net> Message-ID: On 2009-03-27 at 15:03 +0100 Mister Olli sent off: > /usr/src/sys/xen/evtchn/evtchn.c:516: error: conflicting types for 'bind_virq_to_irqhandler' > /usr/src/sys/xen/xen_intr.h:61: error: previous declaration of 'bind_virq_to_irqhandler' was here > /usr/src/sys/xen/evtchn/evtchn.c: In function 'bind_virq_to_irqhandler': > /usr/src/sys/xen/evtchn/evtchn.c:523: error: 'arg' undeclared (first use in this function) > /usr/src/sys/xen/evtchn/evtchn.c:523: error: (Each undeclared identifier is reported only once > /usr/src/sys/xen/evtchn/evtchn.c:523: error: for each function it appears in.) > *** Error code 1 the attached patch should fix this one. Can someone review that please? Thanks Bj?rn -------------- next part -------------- A non-text attachment was scrubbed... Name: freebsd-head-evtchn-build-fix.patch Type: text/x-patch Size: 482 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20090401/36f173cd/freebsd-head-evtchn-build-fix.bin From vince at unsane.co.uk Wed Apr 1 05:04:20 2009 From: vince at unsane.co.uk (Vincent Hoffman) Date: Wed Apr 1 05:04:28 2009 Subject: How can I change the MAC address of ath0? In-Reply-To: References: <1128196a0904010150v572edbd4sb9ab080e2cd8bbb1@mail.gmail.com> Message-ID: <49D35828.6060703@unsane.co.uk> On 1/4/09 09:59, pluknet wrote: > 2009/4/1 XkuIPjIedEYT XkuIPjIedEYT : > >> I'm running the FreeBSD 8.0-CURRENT r190504. >> >> # dmesg | grep ^ath0 >> ath0: mem 0xf4000000-0xf400ffff irq 18 at device 11.0 on pci0 >> ath0: [ITHREAD] >> ath0: AR2413 mac 7.9 RF2413 phy 4.5 >> >> changing the MAC address directly on ath0 didn't work: >> >> # ifconfig ath0 link 00:aa:bb:cc:dd:ee >> ifconfig: ioctl (SIOCAIFADDR): Operation not supported by device >> >> # ifconfig ath0 ether 00:aa:bb:cc:dd:ee >> ifconfig: ioctl (SIOCAIFADDR): Operation not supported by device >> > > It looks that something was changed in this area in r190508. > > I dont have a current system handy so this is conjecture, since the ath device isnt used directly and instead you use cloned wlan devices, could you instead change the MAC address assigned to that instead? Vince From dgerow at afflictions.org Wed Apr 1 05:17:22 2009 From: dgerow at afflictions.org (Damian Gerow) Date: Wed Apr 1 05:17:28 2009 Subject: ZFS checksum errors on USB attach (Was: ZFS data error without reasons) In-Reply-To: <200904010846.55770.hselasky@c2i.net> References: <49BD117B.2080706@163.com> <20090331100328.H46640@rust.salford.ac.uk> <20090401044011.GA51164@plebeian.afflictions.org> <200904010846.55770.hselasky@c2i.net> Message-ID: <20090401121704.GA92522@plebeian.afflictions.org> Hans Petter Selasky wrote: : > I walked over to my laptop (Lenovo X200), and plugged in a Cowon D2 to : > charge up the battery. When I tried to do other things, I received a large : > number of input/output errors, so I knew I'd triggered the bug. Two things : > that I tried to do: : : If you unload "umass" and plug a memory stick, do you see the same behaviour : then? : : Maybe it is not directly USB related. I had previously been unable to produce the same symptoms immediately following a reboot, with no USB-related modules loaded. I will give it another try later today to confirm. - Damian From dfr at rabson.org Wed Apr 1 07:40:25 2009 From: dfr at rabson.org (Doug Rabson) Date: Wed Apr 1 07:41:12 2009 Subject: Compiling CURRENT with XEN config fails In-Reply-To: References: <1238162602.24399.29.camel@phoenix.blechhirn.net> <20090401100438.GA5039@SerNet.DE> Message-ID: On 1 Apr 2009, at 11:32, Bj?rn JACKE wrote: > Hi, > > On 2009-04-01 at 12:04 +0200 Bj?rn JACKE sent off: >> On 2009-03-27 at 15:03 +0100 Mister Olli sent off: >>> /usr/src/sys/xen/evtchn/evtchn.c:516: error: conflicting types for >>> 'bind_virq_to_irqhandler' >>> /usr/src/sys/xen/xen_intr.h:61: error: previous declaration of >>> 'bind_virq_to_irqhandler' was here >>> /usr/src/sys/xen/evtchn/evtchn.c: In function >>> 'bind_virq_to_irqhandler': >>> /usr/src/sys/xen/evtchn/evtchn.c:523: error: 'arg' undeclared >>> (first use in this function) >>> /usr/src/sys/xen/evtchn/evtchn.c:523: error: (Each undeclared >>> identifier is reported only once >>> /usr/src/sys/xen/evtchn/evtchn.c:523: error: for each function it >>> appears in.) >>> *** Error code 1 >> >> the attached patch should fix this one. Can someone review that >> please? > > there are a whole bunch of other compile bugs that had been > introduced with > r189699. Doug, can you please try to do a xen kernel compile with > and without > SMP support and take a look at the issues? I'll sort it out as soon as possible. Sorry for the inconvenience. From xcllnt at mac.com Wed Apr 1 08:26:53 2009 From: xcllnt at mac.com (Marcel Moolenaar) Date: Wed Apr 1 08:27:00 2009 Subject: Removal of GEOM_BSD, GEOM_MBR, GEOM_PC98 and GEOM_SUNLABEL In-Reply-To: <0904011910169.29800@www.mmlab.cse.yzu.edu.tw> References: <95891.1238477069@critter.freebsd.dk> <20090331133132.1e191836@ernst.jennejohn.org> <20090331155542.74d89d64@ernst.jennejohn.org> <60084D1E-9F64-463A-A8E9-7A237D5C7661@mac.com> <0904011910169.29800@www.mmlab.cse.yzu.edu.tw> Message-ID: On Apr 1, 2009, at 4:16 AM, Tai-hwa Liang wrote: > that's too bad. Since my /home is sitting on the extended partition, > the OS won't boot unless the kernel is built with various GEOM_PART_ > removed from i386/conf/DEFAULT plus GEOM_{BSD,MBR} added back to the > kernel configuration file(ie: GENERIC kernel cvsup'ed today doesn't > boot). That sounds like a bug, because logical partitions are supported. Can you enable GEOM_PART_BSD, GEOM_PART_EBR and GEOM_PART_MBR and tell me which GEOMs are available at the mount root prompt? -- Marcel Moolenaar xcllnt@mac.com From bzeeb-lists at lists.zabbadoz.net Wed Apr 1 09:08:23 2009 From: bzeeb-lists at lists.zabbadoz.net (Bjoern A. Zeeb) Date: Wed Apr 1 09:08:31 2009 Subject: Compiling CURRENT with XEN config fails In-Reply-To: References: <1238162602.24399.29.camel@phoenix.blechhirn.net> Message-ID: <20090401154457.K15361@maildrop.int.zabbadoz.net> On Wed, 1 Apr 2009, Bj?rn JACKE wrote: > On 2009-03-27 at 15:03 +0100 Mister Olli sent off: >> /usr/src/sys/xen/evtchn/evtchn.c:516: error: conflicting types for 'bind_virq_to_irqhandler' >> /usr/src/sys/xen/xen_intr.h:61: error: previous declaration of 'bind_virq_to_irqhandler' was here >> /usr/src/sys/xen/evtchn/evtchn.c: In function 'bind_virq_to_irqhandler': >> /usr/src/sys/xen/evtchn/evtchn.c:523: error: 'arg' undeclared (first use in this function) >> /usr/src/sys/xen/evtchn/evtchn.c:523: error: (Each undeclared identifier is reported only once >> /usr/src/sys/xen/evtchn/evtchn.c:523: error: for each function it appears in.) >> *** Error code 1 > > the attached patch should fix this one. Can someone review that please? I had those since last weekend but there are even more ... Not entirely sure about the second hunk of the console.c patch though. I gave up as the universe I built worked for what I tested. Index: sys/dev/xen/console/console.c =================================================================== --- sys/dev/xen/console/console.c (revision 190619) +++ sys/dev/xen/console/console.c (working copy) @@ -225,7 +225,6 @@ xc_attach(device_t dev) { int error; - struct xc_softc *sc = (struct xc_softc *)device_get_softc(dev); if (xen_start_info->flags & SIF_INITDOMAIN) { xc_consdev.cn_putc = xccnputc_dom0; @@ -248,6 +247,7 @@ "console", NULL, xencons_priv_interrupt, + NULL, INTR_TYPE_TTY, NULL); KASSERT(error >= 0, ("can't register console interrupt")); Index: sys/xen/evtchn/evtchn.c =================================================================== --- sys/xen/evtchn/evtchn.c (revision 190619) +++ sys/xen/evtchn/evtchn.c (working copy) @@ -512,7 +512,7 @@ int bind_virq_to_irqhandler(unsigned int virq, unsigned int cpu, const char *devname, driver_filter_t filter, driver_intr_t handler, - unsigned long irqflags, unsigned int *irqp) + void *arg, unsigned long irqflags, unsigned int *irqp) { unsigned int irq; int error; Index: sys/xen/reboot.c =================================================================== --- sys/xen/reboot.c (revision 190619) +++ sys/xen/reboot.c (working copy) @@ -176,9 +176,9 @@ /* * Bind us to CPU 0 and stop any other VCPUs. */ - mtx_lock_spin(&sched_lock); + thread_lock(curthread); sched_bind(curthread, 0); - mtx_unlock_spin(&sched_lock); + thread_unlock(curthread); KASSERT(PCPU_GET(cpuid) == 0, ("xen_suspend: not running on cpu 0")); map = PCPU_GET(other_cpus) & ~stopped_cpus; -- Bjoern A. Zeeb The greatest risk is not taking one. From tinderbox at freebsd.org Wed Apr 1 09:49:55 2009 From: tinderbox at freebsd.org (FreeBSD Tinderbox) Date: Wed Apr 1 09:50:08 2009 Subject: [head tinderbox] failure on ia64/ia64 Message-ID: <20090401164947.873CE7302F@freebsd-current.sentex.ca> TB --- 2009-04-01 14:36:51 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2009-04-01 14:36:51 - starting HEAD tinderbox run for ia64/ia64 TB --- 2009-04-01 14:36:51 - cleaning the object tree TB --- 2009-04-01 14:37:32 - cvsupping the source tree TB --- 2009-04-01 14:37:32 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/ia64/ia64/supfile TB --- 2009-04-01 14:37:40 - building world TB --- 2009-04-01 14:37:40 - MAKEOBJDIRPREFIX=/obj TB --- 2009-04-01 14:37:40 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-04-01 14:37:40 - TARGET=ia64 TB --- 2009-04-01 14:37:40 - TARGET_ARCH=ia64 TB --- 2009-04-01 14:37:40 - TZ=UTC TB --- 2009-04-01 14:37:40 - __MAKE_CONF=/dev/null TB --- 2009-04-01 14:37:40 - cd /src TB --- 2009-04-01 14:37:40 - /usr/bin/make -B buildworld >>> World build started on Wed Apr 1 14:37:42 UTC 2009 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Wed Apr 1 16:27:40 UTC 2009 TB --- 2009-04-01 16:27:40 - generating LINT kernel config TB --- 2009-04-01 16:27:40 - cd /src/sys/ia64/conf TB --- 2009-04-01 16:27:40 - /usr/bin/make -B LINT TB --- 2009-04-01 16:27:40 - building LINT kernel TB --- 2009-04-01 16:27:40 - MAKEOBJDIRPREFIX=/obj TB --- 2009-04-01 16:27:40 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-04-01 16:27:40 - TARGET=ia64 TB --- 2009-04-01 16:27:40 - TARGET_ARCH=ia64 TB --- 2009-04-01 16:27:40 - TZ=UTC TB --- 2009-04-01 16:27:40 - __MAKE_CONF=/dev/null TB --- 2009-04-01 16:27:40 - cd /src TB --- 2009-04-01 16:27:40 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Wed Apr 1 16:27:40 UTC 2009 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ia64/libuwx/src -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -fpic -ffreestanding -Werror vnode_if.c :> hack.c cc -shared -nostdlib hack.c -o hack.So rm -f hack.c MAKE=/usr/bin/make sh /src/sys/conf/newvers.sh LINT cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ia64/libuwx/src -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -fpic -ffreestanding -Werror vers.c linking kernel freebsd32_sysent.o(.data.rel+0x19d0): undefined reference to `freebsd32_sysarch' *** Error code 1 Stop in /obj/ia64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-04-01 16:49:45 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-04-01 16:49:45 - ERROR: failed to build lint kernel TB --- 2009-04-01 16:49:45 - 6522.28 user 458.22 system 7973.66 real http://tinderbox.des.no/tinderbox-head-HEAD-ia64-ia64.full From kostikbel at gmail.com Wed Apr 1 09:58:51 2009 From: kostikbel at gmail.com (Kostik Belousov) Date: Wed Apr 1 09:58:58 2009 Subject: [head tinderbox] failure on ia64/ia64 In-Reply-To: <20090401164947.873CE7302F@freebsd-current.sentex.ca> References: <20090401164947.873CE7302F@freebsd-current.sentex.ca> Message-ID: <20090401165845.GU31897@deviant.kiev.zoral.com.ua> On Wed, Apr 01, 2009 at 11:49:47AM -0500, FreeBSD Tinderbox wrote: > TB --- 2009-04-01 14:36:51 - tinderbox 2.6 running on freebsd-current.sentex.ca > TB --- 2009-04-01 14:36:51 - starting HEAD tinderbox run for ia64/ia64 > TB --- 2009-04-01 14:36:51 - cleaning the object tree > TB --- 2009-04-01 14:37:32 - cvsupping the source tree > TB --- 2009-04-01 14:37:32 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/ia64/ia64/supfile > TB --- 2009-04-01 14:37:40 - building world > TB --- 2009-04-01 14:37:40 - MAKEOBJDIRPREFIX=/obj > TB --- 2009-04-01 14:37:40 - PATH=/usr/bin:/usr/sbin:/bin:/sbin > TB --- 2009-04-01 14:37:40 - TARGET=ia64 > TB --- 2009-04-01 14:37:40 - TARGET_ARCH=ia64 > TB --- 2009-04-01 14:37:40 - TZ=UTC > TB --- 2009-04-01 14:37:40 - __MAKE_CONF=/dev/null > TB --- 2009-04-01 14:37:40 - cd /src > TB --- 2009-04-01 14:37:40 - /usr/bin/make -B buildworld > >>> World build started on Wed Apr 1 14:37:42 UTC 2009 > >>> Rebuilding the temporary build tree > >>> stage 1.1: legacy release compatibility shims > >>> stage 1.2: bootstrap tools > >>> stage 2.1: cleaning up the object tree > >>> stage 2.2: rebuilding the object tree > >>> stage 2.3: build tools > >>> stage 3: cross tools > >>> stage 4.1: building includes > >>> stage 4.2: building libraries > >>> stage 4.3: make dependencies > >>> stage 4.4: building everything > >>> World build completed on Wed Apr 1 16:27:40 UTC 2009 > TB --- 2009-04-01 16:27:40 - generating LINT kernel config > TB --- 2009-04-01 16:27:40 - cd /src/sys/ia64/conf > TB --- 2009-04-01 16:27:40 - /usr/bin/make -B LINT > TB --- 2009-04-01 16:27:40 - building LINT kernel > TB --- 2009-04-01 16:27:40 - MAKEOBJDIRPREFIX=/obj > TB --- 2009-04-01 16:27:40 - PATH=/usr/bin:/usr/sbin:/bin:/sbin > TB --- 2009-04-01 16:27:40 - TARGET=ia64 > TB --- 2009-04-01 16:27:40 - TARGET_ARCH=ia64 > TB --- 2009-04-01 16:27:40 - TZ=UTC > TB --- 2009-04-01 16:27:40 - __MAKE_CONF=/dev/null > TB --- 2009-04-01 16:27:40 - cd /src > TB --- 2009-04-01 16:27:40 - /usr/bin/make -B buildkernel KERNCONF=LINT > >>> Kernel build for LINT started on Wed Apr 1 16:27:40 UTC 2009 > >>> stage 1: configuring the kernel > >>> stage 2.1: cleaning up the object tree > >>> stage 2.2: rebuilding the object tree > >>> stage 2.3: build tools > >>> stage 3.1: making dependencies > >>> stage 3.2: building everything > [...] > cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ia64/libuwx/src -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -fpic -ffreestanding -Werror vnode_if.c > :> hack.c > cc -shared -nostdlib hack.c -o hack.So > rm -f hack.c > MAKE=/usr/bin/make sh /src/sys/conf/newvers.sh LINT > cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ia64/libuwx/src -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -fpic -ffreestanding -Werror vers.c > linking kernel > freebsd32_sysent.o(.data.rel+0x19d0): undefined reference to `freebsd32_sysarch' > *** Error code 1 > > Stop in /obj/ia64/src/sys/LINT. > *** Error code 1 > > Stop in /src. > *** Error code 1 > > Stop in /src. > TB --- 2009-04-01 16:49:45 - WARNING: /usr/bin/make returned exit code 1 > TB --- 2009-04-01 16:49:45 - ERROR: failed to build lint kernel > TB --- 2009-04-01 16:49:45 - 6522.28 user 458.22 system 7973.66 real This is mine. I will fix it shortly. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20090401/c1c5bea7/attachment.pgp From dougb at FreeBSD.org Wed Apr 1 12:20:57 2009 From: dougb at FreeBSD.org (Doug Barton) Date: Wed Apr 1 12:21:03 2009 Subject: New rc.d/named features for testing: auto-forwarding and wait on boot In-Reply-To: <200904010813.57167.mel.flynn+fbsd.current@mailing.thruhere.net> References: <49D1B261.6010406@FreeBSD.org> <200903311025.22219.mel.flynn+fbsd.current@mailing.thruhere.net> <49D27B95.7030209@FreeBSD.org> <200904010813.57167.mel.flynn+fbsd.current@mailing.thruhere.net> Message-ID: <49D3BCF2.9000405@FreeBSD.org> Mel Flynn wrote: > On Tuesday 31 March 2009 22:22:45 Doug Barton wrote: >> Mel Flynn wrote: >>> I think the hardcoded 127.0.0.1 should be configurable especially >>> considering prepend-domain-nameservers option for dhclient.conf(5). >> I'm not sure you understand the goal. The idea here is to use the >> local resolver first, as a forwarder. If that usage would conflict >> with something that you prepend in dhclient.conf, don't enable both >> options. > > But the local resolver is assumed to be 127.0.0.1, not for example > 192.168.1.10 or ::1. Yes. Not only is that considered "best practice," but the named.conf that comes with the system has: listen-on { 127.0.0.1; }; already. There is no good reason to disable that. Adding additional listen-on statements (or other devices) to have the name server listen on other addresses is fine of course. > I agree prepending a nameserver and autoforward are not > the best combo, I never said that, and I don't believe it. Prepending a _local_ name server with an address other than 127.0.0.1 _is_ a bad idea however. > but it can be handy in case you stop named (free up resources, > you temporarily want) to still be able to resolve (though with a delay). > Either way, you're writing 127.0.0.1 to resolv.conf, yet not setting a listen- > on in named so the two can be out of sync, It's already in the default named.conf, and should be there anyway. > And what happens if the DHCP server cannot be reached within 5 tries, but will > once it's in the background? This is actually a good argument for prepending 127.0.0.1 in dhclient.conf. > Also, rcorder shows NETWORKING before named, yet dhclient after, though with > the changes of (a)sync dhclient lately, I should probably familiarize myself > again with what exactly is done. You need to run 'rcorder -s nostart /etc/rc.d/*' to get a better idea of what's happening. The dhclient script is not run by rc, it's run by another script. hth, Doug -- This .signature sanitized for your protection From yanefbsd at gmail.com Wed Apr 1 12:33:19 2009 From: yanefbsd at gmail.com (Garrett Cooper) Date: Wed Apr 1 12:33:25 2009 Subject: Removal of GEOM_BSD, GEOM_MBR, GEOM_PC98 and GEOM_SUNLABEL In-Reply-To: References: <95891.1238477069@critter.freebsd.dk> <20090331133132.1e191836@ernst.jennejohn.org> <20090331155542.74d89d64@ernst.jennejohn.org> <60084D1E-9F64-463A-A8E9-7A237D5C7661@mac.com> <0904011910169.29800@www.mmlab.cse.yzu.edu.tw> Message-ID: <7d6fde3d0904011233v758d337am5e4252adbe5cf58a@mail.gmail.com> On Wed, Apr 1, 2009 at 8:25 AM, Marcel Moolenaar wrote: > > On Apr 1, 2009, at 4:16 AM, Tai-hwa Liang wrote: > >> that's too bad. ?Since my /home is sitting on the extended partition, >> the OS won't boot unless the kernel is built with various GEOM_PART_ >> removed from i386/conf/DEFAULT plus GEOM_{BSD,MBR} added back to the >> kernel configuration file(ie: GENERIC kernel cvsup'ed today doesn't >> boot). > > That sounds like a bug, because logical partitions are > supported. Can you enable GEOM_PART_BSD, GEOM_PART_EBR > and GEOM_PART_MBR and tell me which GEOMs are available > at the mount root prompt? Wait -- you're saying with the new change I'd have to shuffle around my data, redo my 3.5 TB RAID6 array, then shuffle it all back, etc? [gcooper@optimus ~]$ gpart show => 63 312581745 ad4 MBR (149G) 63 134319402 1 freebsd [active] (64G) 134319465 178257240 2 freebsd (85G) 312576705 5103 - free - (2.5M) => 0 134319402 ad4s1 BSD (64G) 0 16777216 2 freebsd-swap (8.0G) 16777216 16777216 1 freebsd-ufs (8.0G) 33554432 16777216 5 freebsd-ufs (8.0G) 50331648 33554432 6 freebsd-ufs (16G) 83886080 16777216 7 freebsd-ufs (8.0G) 100663296 16777216 8 freebsd-ufs (8.0G) 117440512 16878890 4 freebsd-ufs (8.0G) => 0 178257240 ad4s2 BSD (85G) 0 16777216 4 freebsd-ufs (8.0G) 16777216 161480024 5 freebsd-ufs (77G) => 63 4394465208 da0 MBR (2.0T) 63 4294961622 1 !131 [active] (2.0T) 4294961685 99503586 - free - (47G) Btw, what's the replacement for GEOM_* that's getting removed? Thanks, -Garrett From yanefbsd at gmail.com Wed Apr 1 12:35:50 2009 From: yanefbsd at gmail.com (Garrett Cooper) Date: Wed Apr 1 12:35:57 2009 Subject: Removal of GEOM_BSD, GEOM_MBR, GEOM_PC98 and GEOM_SUNLABEL In-Reply-To: <7d6fde3d0904011233v758d337am5e4252adbe5cf58a@mail.gmail.com> References: <95891.1238477069@critter.freebsd.dk> <20090331133132.1e191836@ernst.jennejohn.org> <20090331155542.74d89d64@ernst.jennejohn.org> <60084D1E-9F64-463A-A8E9-7A237D5C7661@mac.com> <0904011910169.29800@www.mmlab.cse.yzu.edu.tw> <7d6fde3d0904011233v758d337am5e4252adbe5cf58a@mail.gmail.com> Message-ID: <7d6fde3d0904011235x404fc7dbo1918d3dbe7ed645a@mail.gmail.com> On Wed, Apr 1, 2009 at 12:33 PM, Garrett Cooper wrote: > On Wed, Apr 1, 2009 at 8:25 AM, Marcel Moolenaar wrote: >> >> On Apr 1, 2009, at 4:16 AM, Tai-hwa Liang wrote: >> >>> that's too bad. ?Since my /home is sitting on the extended partition, >>> the OS won't boot unless the kernel is built with various GEOM_PART_ >>> removed from i386/conf/DEFAULT plus GEOM_{BSD,MBR} added back to the >>> kernel configuration file(ie: GENERIC kernel cvsup'ed today doesn't >>> boot). >> >> That sounds like a bug, because logical partitions are >> supported. Can you enable GEOM_PART_BSD, GEOM_PART_EBR >> and GEOM_PART_MBR and tell me which GEOMs are available >> at the mount root prompt? > > Wait -- you're saying with the new change I'd have to shuffle around > my data, redo my 3.5 TB RAID6 array, then shuffle it all back, etc? > > [gcooper@optimus ~]$ gpart show > => ? ? ? 63 ?312581745 ?ad4 ?MBR ?(149G) > ? ? ? ? 63 ?134319402 ? ?1 ?freebsd ?[active] ?(64G) > ?134319465 ?178257240 ? ?2 ?freebsd ?(85G) > ?312576705 ? ? ? 5103 ? ? ? - free - ?(2.5M) > > => ? ? ? ?0 ?134319402 ?ad4s1 ?BSD ?(64G) > ? ? ? ? ?0 ? 16777216 ? ? ?2 ?freebsd-swap ?(8.0G) > ? 16777216 ? 16777216 ? ? ?1 ?freebsd-ufs ?(8.0G) > ? 33554432 ? 16777216 ? ? ?5 ?freebsd-ufs ?(8.0G) > ? 50331648 ? 33554432 ? ? ?6 ?freebsd-ufs ?(16G) > ? 83886080 ? 16777216 ? ? ?7 ?freebsd-ufs ?(8.0G) > ?100663296 ? 16777216 ? ? ?8 ?freebsd-ufs ?(8.0G) > ?117440512 ? 16878890 ? ? ?4 ?freebsd-ufs ?(8.0G) > > => ? ? ? ?0 ?178257240 ?ad4s2 ?BSD ?(85G) > ? ? ? ? ?0 ? 16777216 ? ? ?4 ?freebsd-ufs ?(8.0G) > ? 16777216 ?161480024 ? ? ?5 ?freebsd-ufs ?(77G) > > => ? ? ? ?63 ?4394465208 ?da0 ?MBR ?(2.0T) > ? ? ? ? ?63 ?4294961622 ? ?1 ?!131 ?[active] ?(2.0T) > ?4294961685 ? ?99503586 ? ? ? - free - ?(47G) > > Btw, what's the replacement for GEOM_* that's getting removed? Or to sum it up a bit better: 1. What's getting removed and why? 2. What's it being replaced with? 3. How do I migrate from the old system to the new one? I don't see that information in the initial warning email. Thanks, -Garrett From xcllnt at mac.com Wed Apr 1 12:44:38 2009 From: xcllnt at mac.com (Marcel Moolenaar) Date: Wed Apr 1 12:44:44 2009 Subject: Removal of GEOM_BSD, GEOM_MBR, GEOM_PC98 and GEOM_SUNLABEL In-Reply-To: <7d6fde3d0904011235x404fc7dbo1918d3dbe7ed645a@mail.gmail.com> References: <95891.1238477069@critter.freebsd.dk> <20090331133132.1e191836@ernst.jennejohn.org> <20090331155542.74d89d64@ernst.jennejohn.org> <60084D1E-9F64-463A-A8E9-7A237D5C7661@mac.com> <0904011910169.29800@www.mmlab.cse.yzu.edu.tw> <7d6fde3d0904011233v758d337am5e4252adbe5cf58a@mail.gmail.com> <7d6fde3d0904011235x404fc7dbo1918d3dbe7ed645a@mail.gmail.com> Message-ID: <94ABEC6B-4AC5-4350-B111-AD9795D4F2ED@mac.com> On Apr 1, 2009, at 12:35 PM, Garrett Cooper wrote: >>> That sounds like a bug, because logical partitions are >>> supported. Can you enable GEOM_PART_BSD, GEOM_PART_EBR >>> and GEOM_PART_MBR and tell me which GEOMs are available >>> at the mount root prompt? >> >> Wait -- you're saying with the new change I'd have to shuffle around >> my data, redo my 3.5 TB RAID6 array, then shuffle it all back, etc? No! hint: GEOM_MBR is not GEOM_PART_MBR. >> > Or to sum it up a bit better: > 1. What's getting removed and why? GEOM_BSD, GEOM_MBR, GEOM_PC98 and GEOM_SUNLABEL They're so yesterday. > 2. What's it being replaced with? GEOM_PART_BSD, GEOM_PART_MBR, GEOM_PART_PC98 and GEOM_PART_VTOC8 > 3. How do I migrate from the old system to the new one? No migration is needed. You already use the new kernel options. All I'm doing is remove the old not-to-be-used options. FYI, -- Marcel Moolenaar xcllnt@mac.com From juhasaarinen at gmail.com Wed Apr 1 14:34:00 2009 From: juhasaarinen at gmail.com (Juha Saarinen) Date: Wed Apr 1 14:34:08 2009 Subject: Kip Macy In-Reply-To: References: <20081223013626.2833a911@baby-jane> <20081223010902.GB1072@in-addr.com> Message-ID: Motion for dismissal of Kip Macy's indictment: http://www.scribd.com/doc/13481284/Kip-Macys-995-Absurd-Indictment -- Juha http://www.techsploder.com From dgerow at afflictions.org Wed Apr 1 16:43:34 2009 From: dgerow at afflictions.org (Damian Gerow) Date: Wed Apr 1 16:43:41 2009 Subject: ZFS checksum errors on USB attach (Was: ZFS data error without reasons) In-Reply-To: <20090401121704.GA92522@plebeian.afflictions.org> References: <49BD117B.2080706@163.com> <20090331100328.H46640@rust.salford.ac.uk> <20090401044011.GA51164@plebeian.afflictions.org> <200904010846.55770.hselasky@c2i.net> <20090401121704.GA92522@plebeian.afflictions.org> Message-ID: <20090401234315.GA11125@plebeian.afflictions.org> Damian Gerow wrote: : : > I walked over to my laptop (Lenovo X200), and plugged in a Cowon D2 to : : > charge up the battery. When I tried to do other things, I received a large : : > number of input/output errors, so I knew I'd triggered the bug. Two things : : > that I tried to do: : : : : If you unload "umass" and plug a memory stick, do you see the same behaviour : : then? : : : : Maybe it is not directly USB related. : : I had previously been unable to produce the same symptoms immediately : following a reboot, with no USB-related modules loaded. I will give it : another try later today to confirm. umass is compiled in to the kernel by default. It's not a module I can load and unload (that I'm aware of, anyhow). So I tried plugging the D2 in, and it didn't cause any troubles. But I wasn't running transmission -- so I started transmission up, plugged the D2 in again, and lo and behold, ZFS checksum errors: ----- Apr 1 19:37:24 plebeian kernel: da1 at umass-sim0 bus 0 target 0 lun 1 Apr 1 19:37:24 plebeian kernel: da1: Removable Direct Access SCSI-0 device Apr 1 19:37:24 plebeian kernel: da1: 40.000MB/s transfers Apr 1 19:37:24 plebeian kernel: da1: 15359MB (31456320 512 byte sectors: 255H 63S/T 1958C) Apr 1 19:37:24 plebeian kernel: GEOM_LABEL: Label for provider da0 is msdosfs/D2. Apr 1 19:37:24 plebeian kernel: GEOM: da1: partition 1 does not start on a track boundary. Apr 1 19:37:24 plebeian kernel: GEOM: da1: partition 1 does not end on a track boundary. Apr 1 19:37:29 plebeian root: ZFS: checksum mismatch, zpool=storage path=/dev/ad4s1d.eli offset=107774476288 size=131072 Apr 1 19:37:29 plebeian root: ZFS: checksum mismatch, zpool=storage path=/dev/ad4s1d.eli offset=107774476288 size=131072 Apr 1 19:37:29 plebeian root: ZFS: zpool I/O failure, zpool=storage error=86 ----- However, the errors are ocurring far less quickly than normal. Could just be coincidence, but I doubt it: closing firefox didn't result in a core dump, but in a proper shutdown procedure. So, this seems to be related to ZFS, and possibly the number of files it has open? Pure speculation on my part, but I only seem to be able to trigger this bug when transmission is open: the only torrent it has loaded is something like 200 files, and 30GB. - Damian From wblock at wonkity.com Wed Apr 1 17:27:13 2009 From: wblock at wonkity.com (User Wblock) Date: Wed Apr 1 17:27:20 2009 Subject: loader prompt doesn't work In-Reply-To: <49D1C3E6.3050207@icyb.net.ua> References: <4451ccf20903300123p4df9c1d7k4c4138ad25d2d4af@mail.gmail.com> <49D0E44C.60103@phat.za.net> <49D1001E.2050405@icyb.net.ua> <49D1C3E6.3050207@icyb.net.ua> Message-ID: On Tue, 31 Mar 2009, Andriy Gapon wrote: > on 31/03/2009 03:50 User Wblock said the following: >> On Mon, 30 Mar 2009, Andriy Gapon wrote: >>> There was a significant fix to boot code made recently by jhb. It is >>> now in head, stable/7 and stable/6. So you need to update to the >>> recent resources. What you also need (and what was not emphasized >>> enough, IMO) is to actually install new boot code (/boot/boot) to >>> your active slices after installworld completes. >>> >>> E.g.: >>> $ gpart bootcode -b /boot/boot adXsY >> >> The gpart manpage just makes me more confused about this. > > Your reply is quite confusing too - you put many different things into > the same heap. Okay, I'll try again. >> I don't know >> what a "protective" MBR is, or if I've got one. > > If you think that you have to know, then google is your friend. The question is "How can I tell if 'gpart bootcode -b /boot/boot adXsY'? is needed? The gpart man page is apparently not the place to start. >> Can you expand on this a little? > > On "this" what? On your statement above: >>> What you also need (and what was not emphasized enough, IMO) is to >>> actually install new boot code (/boot/boot) to your active slices >>> after installworld completes. Would it be more accurate if that sentence read: "What you also need *if you experience problems with the boot loader prompt* (and what was not emphasized enough, IMO)..." >> For instance: >> >> * When did it happen? > > "it" what? >>> There was a significant fix to boot code made recently by jhb. Hoping for something more specific than "recently". >> * Who needs to do this--everyone who has updated to a recent -CURRENT or >> -STABLE? > > If you don't have the problems described earlier in this thread than you > don't have to do anything. Does not having the problem mean the latest boot code is in place, or just that the particular system hasn't triggered the problem? Is there a way to tell if the installed boot code is up to date? >> Or just those using certain partitioning features? >> * There's no mention in /usr/src/UPDATING. Was it mentioned anywhere? -Warren Block * Rapid City, South Dakota USA From avatar at mmlab.cse.yzu.edu.tw Wed Apr 1 18:44:58 2009 From: avatar at mmlab.cse.yzu.edu.tw (Tai-hwa Liang) Date: Wed Apr 1 18:45:06 2009 Subject: Removal of GEOM_BSD, GEOM_MBR, GEOM_PC98 and GEOM_SUNLABEL In-Reply-To: References: <95891.1238477069@critter.freebsd.dk> <20090331133132.1e191836@ernst.jennejohn.org> <20090331155542.74d89d64@ernst.jennejohn.org> <60084D1E-9F64-463A-A8E9-7A237D5C7661@mac.com> <0904011910169.29800@www.mmlab.cse.yzu.edu.tw> Message-ID: <0904020940371.36257@www.mmlab.cse.yzu.edu.tw> On Wed, 1 Apr 2009, Marcel Moolenaar wrote: > > On Apr 1, 2009, at 4:16 AM, Tai-hwa Liang wrote: > >> that's too bad. Since my /home is sitting on the extended partition, >> the OS won't boot unless the kernel is built with various GEOM_PART_ >> removed from i386/conf/DEFAULT plus GEOM_{BSD,MBR} added back to the >> kernel configuration file(ie: GENERIC kernel cvsup'ed today doesn't >> boot). > > That sounds like a bug, because logical partitions are > supported. Can you enable GEOM_PART_BSD, GEOM_PART_EBR > and GEOM_PART_MBR and tell me which GEOMs are available > at the mount root prompt? Following are what gpart sees with a GEOM_PART_{BSD,EBR,MBR} and GEOM_{BSD,MBR} enabled kernel: # gpart show => 63 228338775 ad0 MBR (109G) 63 18688257 1 !12 (8.9G) 18688320 16783200 2 freebsd [active] (8.0G) 35471520 192855600 3 !15 (92G) 228327120 11718 - free - (5.7M) => 0 16783200 ad0s2c BSD (8.0G) 0 786432 1 freebsd-ufs (384M) 786432 4194304 2 freebsd-swap (2.0G) 4980736 393216 4 freebsd-ufs (192M) 5373952 11409248 5 freebsd-ufs (5.4G) # gpart list Geom name: ad0 fwheads: 16 fwsectors: 63 last: 228338837 first: 63 entries: 4 scheme: MBR Providers: 1. Name: ad0s1 Mediasize: 9568387584 (8.9G) Sectorsize: 512 Mode: r0w0e0 rawtype: 12 length: 9568387584 offset: 32256 type: !12 index: 1 end: 18688319 start: 63 2. Name: ad0s2 Mediasize: 8592998400 (8.0G) Sectorsize: 512 Mode: r3w3e3 attrib: active rawtype: 165 length: 8592998400 offset: 9568419840 type: freebsd index: 2 end: 35471519 start: 18688320 3. Name: ad0s3 Mediasize: 98742067200 (92G) Sectorsize: 512 Mode: r0w0e0 rawtype: 15 length: 98742067200 offset: 18161418240 type: !15 index: 3 end: 228327119 start: 35471520 Consumers: 1. Name: ad0 Mediasize: 116909491200 (109G) Sectorsize: 512 Mode: r3w3e6 Geom name: ad0s2c fwheads: 16 fwsectors: 63 last: 16783199 first: 0 entries: 8 scheme: BSD Providers: 1. Name: ad0s2ca Mediasize: 402653184 (384M) Sectorsize: 512 Mode: r0w0e0 rawtype: 7 length: 402653184 offset: 0 type: freebsd-ufs index: 1 end: 786431 start: 0 2. Name: ad0s2cb Mediasize: 2147483648 (2.0G) Sectorsize: 512 Mode: r0w0e0 rawtype: 1 length: 2147483648 offset: 402653184 type: freebsd-swap index: 2 end: 4980735 start: 786432 3. Name: ad0s2cd Mediasize: 201326592 (192M) Sectorsize: 512 Mode: r0w0e0 rawtype: 7 length: 201326592 offset: 2550136832 type: freebsd-ufs index: 4 end: 5373951 start: 4980736 4. Name: ad0s2ce Mediasize: 5841534976 (5.4G) Sectorsize: 512 Mode: r0w0e0 rawtype: 7 length: 5841534976 offset: 2751463424 type: freebsd-ufs index: 5 end: 16783199 start: 5373952 Consumers: 1. Name: ad0s2c Mediasize: 8592998400 (8.0G) Sectorsize: 512 Mode: r0w0e0 Not sure if that's correct but I did not see something like "scheme: EBR" in gpart list. -- Thanks, Tai-hwa Liang From xcllnt at mac.com Wed Apr 1 19:11:38 2009 From: xcllnt at mac.com (Marcel Moolenaar) Date: Wed Apr 1 19:11:45 2009 Subject: Removal of GEOM_BSD, GEOM_MBR, GEOM_PC98 and GEOM_SUNLABEL In-Reply-To: <0904020940371.36257@www.mmlab.cse.yzu.edu.tw> References: <95891.1238477069@critter.freebsd.dk> <20090331133132.1e191836@ernst.jennejohn.org> <20090331155542.74d89d64@ernst.jennejohn.org> <60084D1E-9F64-463A-A8E9-7A237D5C7661@mac.com> <0904011910169.29800@www.mmlab.cse.yzu.edu.tw> <0904020940371.36257@www.mmlab.cse.yzu.edu.tw> Message-ID: <4CCDEFD6-830E-4C8F-B7A2-B7878F8842BE@mac.com> On Apr 1, 2009, at 6:44 PM, Tai-hwa Liang wrote: > On Wed, 1 Apr 2009, Marcel Moolenaar wrote: >> >> On Apr 1, 2009, at 4:16 AM, Tai-hwa Liang wrote: >> >>> that's too bad. Since my /home is sitting on the extended >>> partition, >>> the OS won't boot unless the kernel is built with various GEOM_PART_ >>> removed from i386/conf/DEFAULT plus GEOM_{BSD,MBR} added back to the >>> kernel configuration file(ie: GENERIC kernel cvsup'ed today doesn't >>> boot). >> >> That sounds like a bug, because logical partitions are >> supported. Can you enable GEOM_PART_BSD, GEOM_PART_EBR >> and GEOM_PART_MBR and tell me which GEOMs are available >> at the mount root prompt? > > Following are what gpart sees with a GEOM_PART_{BSD,EBR,MBR} and > GEOM_{BSD,MBR} enabled kernel: Please remove GEOM_{BSD,MBR} when enabling GEOM_PART_{BSD,EBR,MBR} (and vice versa) and let me know how things look then. Thanks, -- Marcel Moolenaar xcllnt@mac.com From alex.wilkinson at dsto.defence.gov.au Wed Apr 1 19:50:40 2009 From: alex.wilkinson at dsto.defence.gov.au (Wilkinson, Alex) Date: Wed Apr 1 19:50:48 2009 Subject: Removal of GEOM_BSD, GEOM_MBR, GEOM_PC98 and GEOM_SUNLABEL In-Reply-To: <94ABEC6B-4AC5-4350-B111-AD9795D4F2ED@mac.com> References: <95891.1238477069@critter.freebsd.dk> <20090331133132.1e191836@ernst.jennejohn.org> <20090331155542.74d89d64@ernst.jennejohn.org> <60084D1E-9F64-463A-A8E9-7A237D5C7661@mac.com> <0904011910169.29800@www.mmlab.cse.yzu.edu.tw> <7d6fde3d0904011233v758d337am5e4252adbe5cf58a@mail.gmail.com> <7d6fde3d0904011235x404fc7dbo1918d3dbe7ed645a@mail.gmail.com> <94ABEC6B-4AC5-4350-B111-AD9795D4F2ED@mac.com> Message-ID: <20090402025021.GD2351@stlux503.dsto.defence.gov.au> 0n Wed, Apr 01, 2009 at 12:44:27PM -0700, Marcel Moolenaar wrote: >> 2. What's it being replaced with? > >GEOM_PART_BSD, GEOM_PART_MBR, GEOM_PART_PC98 and >GEOM_PART_VTOC8 Why ? -aW IMPORTANT: This email remains the property of the Australian Defence Organisation and is subject to the jurisdiction of section 70 of the CRIMES ACT 1914. If you have received this email in error, you are requested to contact the sender and delete the email. From avatar at mmlab.cse.yzu.edu.tw Wed Apr 1 22:17:22 2009 From: avatar at mmlab.cse.yzu.edu.tw (Tai-hwa Liang) Date: Wed Apr 1 22:17:29 2009 Subject: Removal of GEOM_BSD, GEOM_MBR, GEOM_PC98 and GEOM_SUNLABEL In-Reply-To: <4CCDEFD6-830E-4C8F-B7A2-B7878F8842BE@mac.com> References: <95891.1238477069@critter.freebsd.dk> <20090331133132.1e191836@ernst.jennejohn.org> <20090331155542.74d89d64@ernst.jennejohn.org> <60084D1E-9F64-463A-A8E9-7A237D5C7661@mac.com> <0904011910169.29800@www.mmlab.cse.yzu.edu.tw> <0904020940371.36257@www.mmlab.cse.yzu.edu.tw> <4CCDEFD6-830E-4C8F-B7A2-B7878F8842BE@mac.com> Message-ID: <0904021314574.37737@www.mmlab.cse.yzu.edu.tw> On Wed, 1 Apr 2009, Marcel Moolenaar wrote: > On Apr 1, 2009, at 6:44 PM, Tai-hwa Liang wrote: >> On Wed, 1 Apr 2009, Marcel Moolenaar wrote: >>> On Apr 1, 2009, at 4:16 AM, Tai-hwa Liang wrote: >>>> >>>> that's too bad. Since my /home is sitting on the extended partition, >>>> the OS won't boot unless the kernel is built with various GEOM_PART_ >>>> removed from i386/conf/DEFAULT plus GEOM_{BSD,MBR} added back to the >>>> kernel configuration file(ie: GENERIC kernel cvsup'ed today doesn't >>>> boot). >>> >>> That sounds like a bug, because logical partitions are >>> supported. Can you enable GEOM_PART_BSD, GEOM_PART_EBR >>> and GEOM_PART_MBR and tell me which GEOMs are available >>> at the mount root prompt? >> >> Following are what gpart sees with a GEOM_PART_{BSD,EBR,MBR} and >> GEOM_{BSD,MBR} enabled kernel: > > Please remove GEOM_{BSD,MBR} when enabling GEOM_PART_{BSD,EBR,MBR} > (and vice versa) and let me know how things look then. GENERIC kernel as of today(read: with GEOM_PART_{BSD,EBR,MBR} in DEFAULT and no GEOM{BSD,MBR}): # geom show => 63 228338775 ad0 MBR (109G) 63 18688257 1 !12 (8.9G) 18688320 16783200 2 freebsd [active] (8.0G) 35471520 192855600 3 !15 (92G) 228327120 11718 - free - (5.7M) => 0 16783200 ad0s2c BSD (8.0G) 0 786432 1 freebsd-ufs (384M) 786432 4194304 2 freebsd-swap (2.0G) 4980736 393216 4 freebsd-ufs (192M) 5373952 11409248 5 freebsd-ufs (5.4G) # geom list Geom name: ad0 fwheads: 16 fwsectors: 63 last: 228338837 first: 63 entries: 4 scheme: MBR Providers: 1. Name: ad0s1 Mediasize: 9568387584 (8.9G) Sectorsize: 512 Mode: r0w0e0 rawtype: 12 length: 9568387584 offset: 32256 type: !12 index: 1 end: 18688319 start: 63 2. Name: ad0s2 Mediasize: 8592998400 (8.0G) Sectorsize: 512 Mode: r2w2e3 attrib: active rawtype: 165 length: 8592998400 offset: 9568419840 type: freebsd index: 2 end: 35471519 start: 18688320 3. Name: ad0s3 Mediasize: 98742067200 (92G) Sectorsize: 512 Mode: r0w0e0 rawtype: 15 length: 98742067200 offset: 18161418240 type: !15 index: 3 end: 228327119 start: 35471520 Consumers: 1. Name: ad0 Mediasize: 116909491200 (109G) Sectorsize: 512 Mode: r2w2e5 Geom name: ad0s2 fwheads: 16 fwsectors: 63 last: 16783199 first: 0 entries: 8 scheme: BSD Providers: 1. Name: ad0s2a Mediasize: 402653184 (384M) Sectorsize: 512 Mode: r1w1e1 rawtype: 7 length: 402653184 offset: 0 type: freebsd-ufs index: 1 end: 786431 start: 0 2. Name: ad0s2b Mediasize: 2147483648 (2.0G) Sectorsize: 512 Mode: r1w1e0 rawtype: 1 length: 2147483648 offset: 402653184 type: freebsd-swap index: 2 end: 4980735 start: 786432 3. Name: ad0s2d Mediasize: 201326592 (192M) Sectorsize: 512 Mode: r0w0e0 rawtype: 7 length: 201326592 offset: 2550136832 type: freebsd-ufs index: 4 end: 5373951 start: 4980736 4. Name: ad0s2e Mediasize: 5841534976 (5.4G) Sectorsize: 512 Mode: r0w0e0 rawtype: 7 length: 5841534976 offset: 2751463424 type: freebsd-ufs index: 5 end: 16783199 start: 5373952 Consumers: 1. Name: ad0s2 Mediasize: 8592998400 (8.0G) Sectorsize: 512 Mode: r2w2e3 From akm at theinternet.com.au Wed Apr 1 22:51:00 2009 From: akm at theinternet.com.au (Andrew Milton) Date: Wed Apr 1 22:51:09 2009 Subject: Kip Macy In-Reply-To: References: <20081223013626.2833a911@baby-jane> <20081223010902.GB1072@in-addr.com> Message-ID: <20090401233818.GC1035@camelot.theinternet.com.au> +-------[ Juha Saarinen ]---------------------- | Motion for dismissal of Kip Macy's indictment: | | http://www.scribd.com/doc/13481284/Kip-Macys-995-Absurd-Indictment | I hope he gets a discount based on quality of the motion.. My favourite is "... with intent to commit larceny and talking" well I guess if they're going to violate your constititional rights, they might as well arrest you for the intent to talk. -- Andrew Milton akm@theinternet.com.au From rizzo at iet.unipi.it Thu Apr 2 00:00:58 2009 From: rizzo at iet.unipi.it (Luigi Rizzo) Date: Thu Apr 2 00:01:05 2009 Subject: cmpxchg / atomic_cmpset_int emulation for userland (i386) ? Message-ID: <20090402070605.GA96848@onelab2.iet.unipi.it> Hi, I have some list manipulation algorithm that I would like to use that relies rather centrally on atomic_cmpset_int(). This is an atomic instruction on 486+, but not available on 386 and maybe other platforms. i386/atomic.h has a replacement but it uses "pushfl; cli; ... popfl;" so it cannot run in userland. I was wondering if there is a good emulation for that instruction on the i386 that is suitable for userland (other architectures we support have a CPU instruction that does it, or in the case of ARM, a usable emulation for userland). cheers luigi From avg at icyb.net.ua Thu Apr 2 00:40:26 2009 From: avg at icyb.net.ua (Andriy Gapon) Date: Thu Apr 2 00:40:34 2009 Subject: loader prompt doesn't work In-Reply-To: References: <4451ccf20903300123p4df9c1d7k4c4138ad25d2d4af@mail.gmail.com> <49D0E44C.60103@phat.za.net> <49D1001E.2050405@icyb.net.ua> <49D1C3E6.3050207@icyb.net.ua> Message-ID: <49D46BC7.5030307@icyb.net.ua> on 02/04/2009 03:27 User Wblock said the following: > On Tue, 31 Mar 2009, Andriy Gapon wrote: >> on 31/03/2009 03:50 User Wblock said the following: >>> On Mon, 30 Mar 2009, Andriy Gapon wrote: >>>> There was a significant fix to boot code made recently by jhb. It is >>>> now in head, stable/7 and stable/6. So you need to update to the >>>> recent resources. What you also need (and what was not emphasized >>>> enough, IMO) is to actually install new boot code (/boot/boot) to >>>> your active slices after installworld completes. >>>> >>>> E.g.: >>>> $ gpart bootcode -b /boot/boot adXsY >>> >>> The gpart manpage just makes me more confused about this. >> >> Your reply is quite confusing too - you put many different things into >> the same heap. > > Okay, I'll try again. Thank you! >>> I don't know >>> what a "protective" MBR is, or if I've got one. >> >> If you think that you have to know, then google is your friend. > > The question is "How can I tell if 'gpart bootcode -b /boot/boot adXsY'? > is needed? The gpart man page is apparently not the place to start. Well, it is needed if you want to update your btx / boot2 code and not needed otherwise. The manual page can't know your intentions :) >>> Can you expand on this a little? >> >> On "this" what? > > On your statement above: > >>>> What you also need (and what was not emphasized enough, IMO) is to >>>> actually install new boot code (/boot/boot) to your active slices >>>> after installworld completes. > > Would it be more accurate if that sentence read: > > "What you also need *if you experience problems with the boot loader > prompt* (and what was not emphasized enough, IMO)..." Yes, this will definitely be more accurate. OTOH, I think it was clear enough from the context of this thread (e.g. see subject line). >>> For instance: >>> >>> * When did it happen? >> >> "it" what? > >>>> There was a significant fix to boot code made recently by jhb. > > Hoping for something more specific than "recently". http://svn.freebsd.org/viewvc/base/head/sys/boot/i386/btx/btx/ You can easily continue from here. >>> * Who needs to do this--everyone who has updated to a recent -CURRENT or >>> -STABLE? >> >> If you don't have the problems described earlier in this thread than you >> don't have to do anything. > > Does not having the problem mean the latest boot code is in place, or > just that the particular system hasn't triggered the problem? Is there > a way to tell if the installed boot code is up to date? It can mean either. The people who did/do have the problem experienced it very consistently. As for telling - I know of no easy way. You can dd first 8k of your boot slice, hexdump it and then compare with hexdump of /boot/boot installed by installworld. >>> Or just those using certain partitioning features? >>> * There's no mention in /usr/src/UPDATING. Was it mentioned anywhere? BTW, I think it was not mentioned in UPDATING because only a very small minority of users was affected or at least reported the problem. -- Andriy Gapon From kostikbel at gmail.com Thu Apr 2 01:48:41 2009 From: kostikbel at gmail.com (Kostik Belousov) Date: Thu Apr 2 01:48:48 2009 Subject: cmpxchg / atomic_cmpset_int emulation for userland (i386) ? In-Reply-To: <20090402070605.GA96848@onelab2.iet.unipi.it> References: <20090402070605.GA96848@onelab2.iet.unipi.it> Message-ID: <20090402084833.GZ31897@deviant.kiev.zoral.com.ua> On Thu, Apr 02, 2009 at 09:06:05AM +0200, Luigi Rizzo wrote: > Hi, > I have some list manipulation algorithm that I would like to use > that relies rather centrally on atomic_cmpset_int(). > > This is an atomic instruction on 486+, but not available on 386 > and maybe other platforms. i386/atomic.h has a replacement > but it uses "pushfl; cli; ... popfl;" so it cannot run in userland. > > I was wondering if there is a good emulation for that instruction > on the i386 that is suitable for userland (other architectures > we support have a CPU instruction that does it, or in the case of ARM, > a usable emulation for userland). FreeBSD cannot boot on anything < 486, i.e. cmpxchgl and xaddl may be considered always supported by the CPU. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20090402/79da8eb5/attachment.pgp From rizzo at iet.unipi.it Thu Apr 2 01:53:47 2009 From: rizzo at iet.unipi.it (Luigi Rizzo) Date: Thu Apr 2 01:53:55 2009 Subject: cmpxchg / atomic_cmpset_int emulation for userland (i386) ? In-Reply-To: <20090402084833.GZ31897@deviant.kiev.zoral.com.ua> References: <20090402070605.GA96848@onelab2.iet.unipi.it> <20090402084833.GZ31897@deviant.kiev.zoral.com.ua> Message-ID: <20090402085854.GA2237@onelab2.iet.unipi.it> On Thu, Apr 02, 2009 at 11:48:33AM +0300, Kostik Belousov wrote: > On Thu, Apr 02, 2009 at 09:06:05AM +0200, Luigi Rizzo wrote: > > Hi, > > I have some list manipulation algorithm that I would like to use > > that relies rather centrally on atomic_cmpset_int(). > > > > This is an atomic instruction on 486+, but not available on 386 > > and maybe other platforms. i386/atomic.h has a replacement > > but it uses "pushfl; cli; ... popfl;" so it cannot run in userland. > > > > I was wondering if there is a good emulation for that instruction > > on the i386 that is suitable for userland (other architectures > > we support have a CPU instruction that does it, or in the case of ARM, > > a usable emulation for userland). > > FreeBSD cannot boot on anything < 486, i.e. cmpxchgl and xaddl may be > considered always supported by the CPU. It was a slightly more generic question -- this stuff is for userland so while we can assume it works on modern FreeBSD versions, I would like to see what constraints it has on older versions of FreeBSD. Of course I can emulate the critical section with a pthread lock, but that would be the worst case option. cheers luigi From kostikbel at gmail.com Thu Apr 2 02:47:32 2009 From: kostikbel at gmail.com (Kostik Belousov) Date: Thu Apr 2 02:47:40 2009 Subject: cmpxchg / atomic_cmpset_int emulation for userland (i386) ? In-Reply-To: <20090402085854.GA2237@onelab2.iet.unipi.it> References: <20090402070605.GA96848@onelab2.iet.unipi.it> <20090402084833.GZ31897@deviant.kiev.zoral.com.ua> <20090402085854.GA2237@onelab2.iet.unipi.it> Message-ID: <20090402094727.GC31897@deviant.kiev.zoral.com.ua> On Thu, Apr 02, 2009 at 10:58:54AM +0200, Luigi Rizzo wrote: > On Thu, Apr 02, 2009 at 11:48:33AM +0300, Kostik Belousov wrote: > > On Thu, Apr 02, 2009 at 09:06:05AM +0200, Luigi Rizzo wrote: > > > Hi, > > > I have some list manipulation algorithm that I would like to use > > > that relies rather centrally on atomic_cmpset_int(). > > > > > > This is an atomic instruction on 486+, but not available on 386 > > > and maybe other platforms. i386/atomic.h has a replacement > > > but it uses "pushfl; cli; ... popfl;" so it cannot run in userland. > > > > > > I was wondering if there is a good emulation for that instruction > > > on the i386 that is suitable for userland (other architectures > > > we support have a CPU instruction that does it, or in the case of ARM, > > > a usable emulation for userland). > > > > FreeBSD cannot boot on anything < 486, i.e. cmpxchgl and xaddl may be > > considered always supported by the CPU. > > It was a slightly more generic question -- this stuff is for userland > so while we can assume it works on modern FreeBSD versions, I would > like to see what constraints it has on older versions of FreeBSD. > Of course I can emulate the critical section with a pthread lock, > but that would be the worst case option. Support for FPU-less operations was removed from HEAD in Jul 2003. The support for i386+387 seems to be removed in 2004, i.e. before 5.x. The kernel explicitely requires working read-only mappings of the pages for kernel mode, AKA WP bit in CR0. Also, kernel assumes that cmpxchgl is always present. Do you want to support 4.x ? -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20090402/12665f62/attachment.pgp From sobomax at FreeBSD.org Thu Apr 2 03:00:28 2009 From: sobomax at FreeBSD.org (Maxim Sobolev) Date: Thu Apr 2 03:00:37 2009 Subject: cmpxchg / atomic_cmpset_int emulation for userland (i386) ? In-Reply-To: <20090402085854.GA2237@onelab2.iet.unipi.it> References: <20090402070605.GA96848@onelab2.iet.unipi.it> <20090402084833.GZ31897@deviant.kiev.zoral.com.ua> <20090402085854.GA2237@onelab2.iet.unipi.it> Message-ID: <49D48CA7.9050102@FreeBSD.org> Luigi Rizzo wrote: > On Thu, Apr 02, 2009 at 11:48:33AM +0300, Kostik Belousov wrote: >> On Thu, Apr 02, 2009 at 09:06:05AM +0200, Luigi Rizzo wrote: >>> Hi, >>> I have some list manipulation algorithm that I would like to use >>> that relies rather centrally on atomic_cmpset_int(). >>> >>> This is an atomic instruction on 486+, but not available on 386 >>> and maybe other platforms. i386/atomic.h has a replacement >>> but it uses "pushfl; cli; ... popfl;" so it cannot run in userland. >>> >>> I was wondering if there is a good emulation for that instruction >>> on the i386 that is suitable for userland (other architectures >>> we support have a CPU instruction that does it, or in the case of ARM, >>> a usable emulation for userland). >> FreeBSD cannot boot on anything < 486, i.e. cmpxchgl and xaddl may be >> considered always supported by the CPU. > > It was a slightly more generic question -- this stuff is for userland > so while we can assume it works on modern FreeBSD versions, I would > like to see what constraints it has on older versions of FreeBSD. > Of course I can emulate the critical section with a pthread lock, > but that would be the worst case option. On i386's you can use XCHG instruction to implement locks and test&set in userland. Check this: http://lists.canonical.org/pipermail/kragen-tol/1999-August/000457.html http://www.acm.uiuc.edu/sigops/roll_your_own/i386/atomic.html The simplest is the XCHG instruction, which can be used to atomically exchange two registers or a register and a memory location. This makes it possible to implement multiple exclusion; reserve a particular location in RAM as a mutex, and initially set it to 1. To acquire the mutex, set a register to 0, and XCHG it with the location in RAM. If what you get back is a 1, then you have successfully acquired the mutex; otherwise, someone else has it. You can return the mutex simply by setting the location to a nonzero value. Intel's doc says, "When a memory operand is used with the XCHG instruction, the processor's LOCK signal is automatically asserted. This instruction is thus useful for implementing semaphores or similar data structures for process synchronization." -Maxim From ccuiyyan at gmail.com Thu Apr 2 03:19:31 2009 From: ccuiyyan at gmail.com (=?GB2312?B?tN7R0mNjdWl5eWFuQHNpbmEuY29t?=) Date: Thu Apr 2 03:19:37 2009 Subject: dup() scales badly on multicore platform Message-ID: <4451ccf20904020319r6b66f390vebbb678b9e8eb2ab@mail.gmail.com> Dear all; i benchchmark the dup() system call on 32 cores machine in FreeBSD-current8.0. The results are bad. The phenomenon is easy to come out. Each process(not thread) on the core dup() its private file, and close() in a tight loop. The time completing the parallel workload is considered as performance. At first, i think there are some locks. However, lock profiling in FreeBSD is strange and interesting. I attach the graph and lock profiling. Any ideas? -------------- next part -------------- A non-text attachment was scrubbed... Name: TCCC Type: application/octet-stream Size: 4867 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20090402/d8432ee4/TCCC.obj From rwatson at FreeBSD.org Thu Apr 2 03:52:39 2009 From: rwatson at FreeBSD.org (Robert Watson) Date: Thu Apr 2 03:52:51 2009 Subject: dup() scales badly on multicore platform In-Reply-To: <4451ccf20904020319r6b66f390vebbb678b9e8eb2ab@mail.gmail.com> References: <4451ccf20904020319r6b66f390vebbb678b9e8eb2ab@mail.gmail.com> Message-ID: On Thu, 2 Apr 2009, $BVC4d(Jccuiyyan@sina.com wrote: > i benchchmark the dup() system call on 32 cores machine in > FreeBSD-current8.0. > > The results are bad. The phenomenon is easy to come out. Each > process(not thread) on the core > > dup() its private file, and close() in a tight loop. The time > completing the parallel workload > > is considered as performance. At first, i think there are some locks. > However, lock profiling > > in FreeBSD is strange and interesting. I attach the graph and lock > profiling. Any ideas? Could you post your benchmark code? It sounds from the above as though you have 32 processes, ecah dup'ing and closing a descriptor originally created in that process (and not a shared descriptor with other processes)? Robert N M Watson Computer Laboratory University of Cambridge From ccuiyyan at gmail.com Thu Apr 2 03:14:41 2009 From: ccuiyyan at gmail.com (=?GB2312?B?tN7R0mNjdWl5eWFuQHNpbmEuY29t?=) Date: Thu Apr 2 04:20:09 2009 Subject: dup() scales badly on multicore platform Message-ID: <4451ccf20904020314r7591a546l89573aa76a44143a@mail.gmail.com> Dear all; i benchchmark the dup() system call on 32 cores machine in FreeBSD-current8.0. The results are bad. The phenomenon is easy to come out. Each process(not thread) on the core dup() its private file, and close() in a tight loop. The time completing the parallel workload is considered as performance. At first, i think there are some locks. However, lock profiling in FreeBSD is strange and interesting. I attach the graph and lock profiling. Any ideas? Best Wishes! Yan -------------- next part -------------- A non-text attachment was scrubbed... Name: LOCK32 Type: application/octet-stream Size: 227887 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20090402/6bd837ce/LOCK32-0001.obj From bsam at ipt.ru Thu Apr 2 06:39:35 2009 From: bsam at ipt.ru (Boris Samorodov) Date: Thu Apr 2 06:39:48 2009 Subject: FreeBSD 8.0-CUR: /usr/ports/x11/linux-f8-xorg-libs won't install although emulators/linux_base-f8 is already installed In-Reply-To: <49D4BD74.30608@web.de> (O. Hartmann's message of "Thu\, 02 Apr 2009 13\:28\:20 +0000") References: <49D4BD74.30608@web.de> Message-ID: <14512074@bb.ipt.ru> On Thu, 02 Apr 2009 13:28:20 +0000 O. Hartmann wrote: > Before filing a PR I will ask for hints for a problem I revealed when > I wanted installing usr/ports/x11/linux-f8-xorg-libs on a FreeBSD > 8.0-CURRENT/amd64 box (most recent build_world, ports tree up to > date). > I receive this error: > ===> linux-f8-xorg-libs-7.3 the port should be used with > linux_base-f8, please read /usr/ports/UPDATING. There was an error at /usr/ports/UPDATING, I committed a fix two hours ago. You should define at /etc/make.conf variables: OVERRIDE_LINUX_BASE_PORT=f8 OVERRIDE_LINUX_NONBASE_PORTS=f8 > *** Error code 1 > Stop in /usr/ports/x11/linux-f8-xorg-libs. > Package /usr/ports/emulators/linux_base-f8 is already installed, up to > date and Linux kernel module is also running and showing up when doing > kldstat adjacent with linprocfs and linsysfs. > What's wrong? HTH & WBR -- Boris Samorodov (bsam) Research Engineer, http://www.ipt.ru Telephone & Internet SP FreeBSD Committer, http://www.FreeBSD.org The Power To Serve From ohartman at web.de Thu Apr 2 06:29:52 2009 From: ohartman at web.de (O. Hartmann) Date: Thu Apr 2 06:53:05 2009 Subject: FreeBSD 8.0-CUR: /usr/ports/x11/linux-f8-xorg-libs won't install although emulators/linux_base-f8 is already installed Message-ID: <49D4BD74.30608@web.de> Before filing a PR I will ask for hints for a problem I revealed when I wanted installing usr/ports/x11/linux-f8-xorg-libs on a FreeBSD 8.0-CURRENT/amd64 box (most recent build_world, ports tree up to date). I receive this error: ===> linux-f8-xorg-libs-7.3 the port should be used with linux_base-f8, please read /usr/ports/UPDATING. *** Error code 1 Stop in /usr/ports/x11/linux-f8-xorg-libs. Package /usr/ports/emulators/linux_base-f8 is already installed, up to date and Linux kernel module is also running and showing up when doing kldstat adjacent with linprocfs and linsysfs. What's wrong? Oliver From sgk at troutmask.apl.washington.edu Thu Apr 2 07:16:10 2009 From: sgk at troutmask.apl.washington.edu (Steve Kargl) Date: Thu Apr 2 07:16:23 2009 Subject: FreeBSD 8.0-CUR: /usr/ports/x11/linux-f8-xorg-libs won't install although emulators/linux_base-f8 is already installed In-Reply-To: <49D4BD74.30608@web.de> References: <49D4BD74.30608@web.de> Message-ID: <20090402141610.GA55696@troutmask.apl.washington.edu> On Thu, Apr 02, 2009 at 01:28:20PM +0000, O. Hartmann wrote: > Before filing a PR I will ask for hints for a problem I revealed when I > wanted installing usr/ports/x11/linux-f8-xorg-libs on a FreeBSD > 8.0-CURRENT/amd64 box (most recent build_world, ports tree up to date). > I receive this error: > > ===> linux-f8-xorg-libs-7.3 the port should be used with linux_base-f8, > please read /usr/ports/UPDATING. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > *** Error code 1 > > Stop in /usr/ports/x11/linux-f8-xorg-libs. > > > Package /usr/ports/emulators/linux_base-f8 is already installed, up to > date and Linux kernel module is also running and showing up when doing > kldstat adjacent with linprocfs and linsysfs. > > What's wrong? > See above? -- Steve From ohartman at zedat.fu-berlin.de Thu Apr 2 07:47:10 2009 From: ohartman at zedat.fu-berlin.de (O. Hartmann) Date: Thu Apr 2 07:47:24 2009 Subject: FreeBSD 8.0-CUR: /usr/ports/x11/linux-f8-xorg-libs won't install although emulators/linux_base-f8 is already installed In-Reply-To: <14512074@bb.ipt.ru> References: <49D4BD74.30608@web.de> <14512074@bb.ipt.ru> Message-ID: <49D4CF93.8000906@zedat.fu-berlin.de> Boris Samorodov wrote: > On Thu, 02 Apr 2009 13:28:20 +0000 O. Hartmann wrote: > >> Before filing a PR I will ask for hints for a problem I revealed when >> I wanted installing usr/ports/x11/linux-f8-xorg-libs on a FreeBSD >> 8.0-CURRENT/amd64 box (most recent build_world, ports tree up to >> date). >> I receive this error: > >> ===> linux-f8-xorg-libs-7.3 the port should be used with >> linux_base-f8, please read /usr/ports/UPDATING. > > There was an error at /usr/ports/UPDATING, I committed a fix two > hours ago. You should define at /etc/make.conf variables: > OVERRIDE_LINUX_BASE_PORT=f8 > OVERRIDE_LINUX_NONBASE_PORTS=f8 > >> *** Error code 1 > >> Stop in /usr/ports/x11/linux-f8-xorg-libs. > > >> Package /usr/ports/emulators/linux_base-f8 is already installed, up to >> date and Linux kernel module is also running and showing up when doing >> kldstat adjacent with linprocfs and linsysfs. > >> What's wrong? > > HTH & WBR After adding both lines as recommended everything worked well! Thanks. From xcllnt at mac.com Thu Apr 2 09:45:19 2009 From: xcllnt at mac.com (Marcel Moolenaar) Date: Thu Apr 2 09:45:25 2009 Subject: Removal of GEOM_BSD, GEOM_MBR, GEOM_PC98 and GEOM_SUNLABEL In-Reply-To: <0904021314574.37737@www.mmlab.cse.yzu.edu.tw> References: <95891.1238477069@critter.freebsd.dk> <20090331133132.1e191836@ernst.jennejohn.org> <20090331155542.74d89d64@ernst.jennejohn.org> <60084D1E-9F64-463A-A8E9-7A237D5C7661@mac.com> <0904011910169.29800@www.mmlab.cse.yzu.edu.tw> <0904020940371.36257@www.mmlab.cse.yzu.edu.tw> <4CCDEFD6-830E-4C8F-B7A2-B7878F8842BE@mac.com> <0904021314574.37737@www.mmlab.cse.yzu.edu.tw> Message-ID: On Apr 1, 2009, at 10:16 PM, Tai-hwa Liang wrote: > GENERIC kernel as of today(read: with GEOM_PART_{BSD,EBR,MBR} in > DEFAULT > and no GEOM{BSD,MBR}): > > # geom show > => 63 228338775 ad0 MBR (109G) > 63 18688257 1 !12 (8.9G) > 18688320 16783200 2 freebsd [active] (8.0G) > 35471520 192855600 3 !15 (92G) > 228327120 11718 - free - (5.7M) Can you dump the first 2 sectors of slice 3 and send it to me: dd if=/dev/ad0s3 of=/tmp/dump.dd count=2 bs=512 I suspect the EBR has some data where it shouldn't and as such is rejected by the EBR scheme. Could you also send me the confxml output: sysctl -b kern.geom.confxml > geom.xml Thanks! -- Marcel Moolenaar xcllnt@mac.com From xcllnt at mac.com Thu Apr 2 10:00:13 2009 From: xcllnt at mac.com (Marcel Moolenaar) Date: Thu Apr 2 10:00:25 2009 Subject: Removal of GEOM_BSD, GEOM_MBR, GEOM_PC98 and GEOM_SUNLABEL In-Reply-To: <20090402025021.GD2351@stlux503.dsto.defence.gov.au> References: <95891.1238477069@critter.freebsd.dk> <20090331133132.1e191836@ernst.jennejohn.org> <20090331155542.74d89d64@ernst.jennejohn.org> <60084D1E-9F64-463A-A8E9-7A237D5C7661@mac.com> <0904011910169.29800@www.mmlab.cse.yzu.edu.tw> <7d6fde3d0904011233v758d337am5e4252adbe5cf58a@mail.gmail.com> <7d6fde3d0904011235x404fc7dbo1918d3dbe7ed645a@mail.gmail.com> <94ABEC6B-4AC5-4350-B111-AD9795D4F2ED@mac.com> <20090402025021.GD2351@stlux503.dsto.defence.gov.au> Message-ID: <41AA874E-3A8D-4059-9B60-BCE91051BB0C@mac.com> On Apr 1, 2009, at 7:50 PM, Wilkinson, Alex wrote: > > 0n Wed, Apr 01, 2009 at 12:44:27PM -0700, Marcel Moolenaar wrote: > >>> 2. What's it being replaced with? >> >> GEOM_PART_BSD, GEOM_PART_MBR, GEOM_PART_PC98 and >> GEOM_PART_VTOC8 > > Why ? It's a better basis for further growth. It has a uniform interface which allows us to improve sysinstall and add GPT on i386 or even APM on PowerPC (you'd expect we have that already, but we don't). We can even modify logical partitions then, something we cannot do now. We can have a tool like parted... It allows us to add "advanced" features like moving a partition that's mounted or resizing a partition that has been formatted without reformatting. Or even the ability to migrate a MBR+BSD partitioning scheme into a GPT one while the system is running from the disk. -- Marcel Moolenaar xcllnt@mac.com From babkin at verizon.net Thu Apr 2 11:48:28 2009 From: babkin at verizon.net (Sergey Babkin) Date: Thu Apr 2 12:07:59 2009 Subject: Improving the kernel/i386 timecounter performance (GSoC proposal) Message-ID: <6547642.196222.1238698084570.JavaMail.root@vms062.mailsrvcs.net> Apr 2, 2009 01:03:48 AM, [1]peterjeremy@optushome.com.au wrot >On 2009-Mar-30 18:45:30 -0700, Maxim Sobolev <[2]sobomax@freebsd.org> wrote: >>You don't really need to It >>could be done on de certain >>threshold, its >>open/ > >Th >appro some >inf deemed > >A not > in & Does it make sense to even bother with lazy mapping? is a very minor activity compared to mapping and linking the overhead won't be even noticeable. If you more should not make much difference. -SB References 1. 3D"mailto:peterjeremy@optushome.com.au" 2. file://localhost/tmp/3D"m From julian at elischer.org Thu Apr 2 12:18:38 2009 From: julian at elischer.org (Julian Elischer) Date: Thu Apr 2 12:18:56 2009 Subject: Improving the kernel/i386 timecounter performance (GSoC proposal) In-Reply-To: <6547642.196222.1238698084570.JavaMail.root@vms062.mailsrvcs.net> References: <6547642.196222.1238698084570.JavaMail.root@vms062.mailsrvcs.net> Message-ID: <49D50FA6.1020202@elischer.org> Hey Sergey, whatever you are using for a mail client SUCKS real bad at the moment.. it's really messing up your outgoing mails.. note the mail below.... Sergey Babkin wrote: > Apr 2, 2009 01:03:48 AM, [1]peterjeremy@optushome.com.au wrot= : > >On 2009-Mar-30 18:45:30 -0700, Maxim Sobolev <[2]sobomax@freebsd.org> > wrote: > >>You don't really need to =o it on every execve() unconditionally. > It > >>could be done on de=and in libc, so that only when thread pass > certain > >>threshold, =he "common page optimization code" kicks in and does > its > >>open/=map/etc magic. Otherwise, "normal" syscall is performed. > > > >Th=s "optimisation" is premature. First step is to implement an > >appro=ch that always maps (or whatever) the data and then gather > some > >inf=rmation about its overheads in the real world. If they are > deemed > >=xcessive, only then do we start looking at how to improve things. > >A=d IMO, the first step would be to lazily map the page - so it's > not > >=mapped by default but mapped the first time any of the information > in > &=t;it is used. > Does it make sense to even bother with lazy mapping? =fter all, this > is a very minor > activity compared to mapping and linking=he dynamic libc. I think > the overhead > won't be even noticeable. If you=lready map 200 pages, adding one > more should not > make much difference. -SB > > References > > 1. 3D"mailto:peterjeremy@optushome.com.au" > 2. file://localhost/tmp/3D"m_______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" From mister.olli at googlemail.com Thu Apr 2 12:35:06 2009 From: mister.olli at googlemail.com (Mister Olli) Date: Thu Apr 2 12:35:18 2009 Subject: Compiling CURRENT with XEN config fails In-Reply-To: References: <1238162602.24399.29.camel@phoenix.blechhirn.net> Message-ID: <1238700894.14361.615.camel@phoenix.blechhirn.net> Hi, the attached patch fixed the compile problem, but new ones are coming up (on r190464) ;-)) cc -c -O -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -fstack-protector -Werror /usr/src/sys/xen/reboot.c /usr/src/sys/xen/reboot.c: In function 'xen_suspend': /usr/src/sys/xen/reboot.c:179: error: 'sched_lock' undeclared (first use in this function) /usr/src/sys/xen/reboot.c:179: error: (Each undeclared identifier is reported only once /usr/src/sys/xen/reboot.c:179: error: for each function it appears in.) cc1: warnings being treated as errors /usr/src/sys/xen/reboot.c:216: warning: implicit declaration of function 'pmap_suspend' /usr/src/sys/xen/reboot.c:216: warning: nested extern declaration of 'pmap_suspend' /usr/src/sys/xen/reboot.c:218: warning: implicit declaration of function 'pmap_resume' /usr/src/sys/xen/reboot.c:218: warning: nested extern declaration of 'pmap_resume' /usr/src/sys/xen/reboot.c:224: error: 'xen_pfn_to_mfn_frame_list_list' undeclared (first use in this function) /usr/src/sys/xen/reboot.c:231: error: 'xen_pfn_to_mfn_frame_list' undeclared (first use in this function) *** Error code 1 Stop in /usr/obj/usr/src/sys/XEN. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. template-8_CURRENT# with a current revision (190640) 'make depend' fails with these errors: ===> sbin/ifconfig (depend) rm -f .depend mkdep -f .depend -a ifconfig.c af_link.c af_inet.c af_inet6.c af_atalk.c ifclone.c ifmac.c ifmedia.c ifvlan.c ifgre.c ifieee80211.c regdomain.c ifcarp.c ifgroup.c ifpfsync.c ifbridge.c iflagg.c af_ipx.c ifieee80211.c:82:39: error: net80211/ieee80211_superg.h: No such file or directory mkdep: compile failed *** Error code 1 Stop in /usr/src/sbin/ifconfig. *** Error code 1 Regards, Olli On Mi, 2009-04-01 at 12:04 +0200, Bj?rn JACKE wrote: > On 2009-03-27 at 15:03 +0100 Mister Olli sent off: > > /usr/src/sys/xen/evtchn/evtchn.c:516: error: conflicting types for 'bind_virq_to_irqhandler' > > /usr/src/sys/xen/xen_intr.h:61: error: previous declaration of 'bind_virq_to_irqhandler' was here > > /usr/src/sys/xen/evtchn/evtchn.c: In function 'bind_virq_to_irqhandler': > > /usr/src/sys/xen/evtchn/evtchn.c:523: error: 'arg' undeclared (first use in this function) > > /usr/src/sys/xen/evtchn/evtchn.c:523: error: (Each undeclared identifier is reported only once > > /usr/src/sys/xen/evtchn/evtchn.c:523: error: for each function it appears in.) > > *** Error code 1 > > the attached patch should fix this one. Can someone review that please? > > Thanks > Bj?rn From ivoras at freebsd.org Thu Apr 2 13:25:35 2009 From: ivoras at freebsd.org (Ivan Voras) Date: Thu Apr 2 13:25:43 2009 Subject: strange UFS labels behaviour In-Reply-To: <367b2c980903311133v37833cabla4934f8b1a9b5e15@mail.gmail.com> References: <367b2c980903311133v37833cabla4934f8b1a9b5e15@mail.gmail.com> Message-ID: Olivier SMEDTS wrote: > Hi, > > Since UFS labels were introduced, I've got strange behaviour when > fsck-ing or mounting my UFS partitions. Here is the console output at > boot : > Is this expected ? I didn't read your message in detail but if are you asking if the "label ... removed" are valid when the device is opened from an "alternative" entry point (e.g. ad0s1e instead of ufsid/4867d45fd3972203) then yes, this is by design. The label is read from the file system metadata and anything that opens that file system for its own use can change this metadata - so the labels are removed. (note that this is nothing special as far as GEOM_LABEL is concerned - this is present in all types and forms of labels). If you're complaining about the verbosity of the whole process then I think you can set the kern.geom.label.debug sysctl to -1 to avoid these messages. The "modern" way would be to use the labels as device nodes for mounting instead of raw devices - in this case they would "stay" when opened. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 258 bytes Desc: OpenPGP digital signature Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20090402/4ee4b3a0/signature.pgp From avatar at mmlab.cse.yzu.edu.tw Thu Apr 2 18:35:26 2009 From: avatar at mmlab.cse.yzu.edu.tw (Tai-hwa Liang) Date: Thu Apr 2 18:35:33 2009 Subject: Removal of GEOM_BSD, GEOM_MBR, GEOM_PC98 and GEOM_SUNLABEL In-Reply-To: References: <95891.1238477069@critter.freebsd.dk> <20090331133132.1e191836@ernst.jennejohn.org> <20090331155542.74d89d64@ernst.jennejohn.org> <60084D1E-9F64-463A-A8E9-7A237D5C7661@mac.com> <0904011910169.29800@www.mmlab.cse.yzu.edu.tw> <0904020940371.36257@www.mmlab.cse.yzu.edu.tw> <4CCDEFD6-830E-4C8F-B7A2-B7878F8842BE@mac.com> <0904021314574.37737@www.mmlab.cse.yzu.edu.tw> Message-ID: <09040309313414.76643@www.mmlab.cse.yzu.edu.tw> On Thu, 2 Apr 2009, Marcel Moolenaar wrote: > Can you dump the first 2 sectors of slice 3 and > send it to me: > dd if=/dev/ad0s3 of=/tmp/dump.dd count=2 bs=512 00000000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 00000010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 00000020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 00000030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 00000040 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 00000050 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 00000060 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 00000070 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 00000080 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 00000090 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 000000a0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 000000b0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 000000c0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 000000d0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 000000e0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 000000f0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 00000100 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 00000110 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 00000120 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 00000130 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 00000140 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 00000150 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 00000160 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 00000170 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 00000180 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 00000190 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 000001a0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 000001b0 00 00 00 00 00 f2 0e 00 00 00 00 00 00 00 00 01 |................| 000001c0 c1 ff 83 ef ff ff 3f 00 00 00 21 17 00 01 00 00 |......?...!.....| 000001d0 c1 ff 05 ef ff ff 60 17 00 01 b0 a8 fe 02 00 00 |......`.........| 000001e0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 000001f0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 55 aa |..............U.| 00000200 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 00000210 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 00000220 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 00000230 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 00000240 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 00000250 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 00000260 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 00000270 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 00000280 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 00000290 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 000002a0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 000002b0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 000002c0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 000002d0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 000002e0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 000002f0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 00000300 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 00000310 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 00000320 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 00000330 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 00000340 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 00000350 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 00000360 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 00000370 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 00000380 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 00000390 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 000003a0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 000003b0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 000003c0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 000003d0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 000003e0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 000003f0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 00000400 > I suspect the EBR has some data where it shouldn't and > as such is rejected by the EBR scheme. > > Could you also send me the confxml output: > sysctl -b kern.geom.confxml > geom.xml A working(w/ GEOM_{MBR,BSD}, w/o GEOM_PART_{MBR,EBR,BSD}) kernel: MD md0 1 r1w1e1 md0 536870912 512 0 512 0 0 536870912 swap ACD acd0 1 r0w0e0 acd0 8796093020160 2048 BSD ad0s7 4 512 18161418240 18161418240 r1w1e2 r0w0e0 ad0s7c 16000492032 512 2 16000492032 31250961 0 0 0 r1w1e1 ad0s7a 16000483840 512 0 16000483840 31250945 0 0 7 ad0s2 3 512 9568419840 9568419840 r4w4e4 r1w1e1 ad0s2e 5841534976 512 4 5841534976 11409248 2751463424 5373952 7 r1w1e1 ad0s2d 201326592 512 3 201326592 393216 2550136832 4980736 7 r0w0e0 ad0s2c 8592998400 512 2 8592998400 16783200 0 0 0 r1w1e0 ad0s2b 2147483648 512 1 2147483648 4194304 402653184 786432 1 r1w1e1 ad0s2a 402653184 512 0 402653184 786432 0 0 7 PART VFS ffs.md0 2 r1w1e1 msdosfs.ad0s6 4 r1w1e1 msdosfs.ad0s1 3 r1w1e1 ffs.ad0s7a 5 r1w1e1 ffs.ad0s2e 4 r1w1e1 ffs.ad0s2d 4 r1w1e1 ffs.ad0s2a 4 r1w1e1 DISK cd0 1 r0w0e0 cd0 0 2048 0 0 ad0 1 r7w7e10 ad0 116909491200 512 16 63 MBR ad0 2 r7w7e10 r2w2e4 ad0s3 98742067200 512 2 98742067200 192855600 18161418240 35471520 15 r4w4e4 ad0s2 8592998400 512 1 8592998400 16783200 9568419840 18688320 165 r1w1e1 ad0s1 9568387584 512 0 9568387584 18688257 32256 63 12 MBREXT ad0s3 3 r2w2e4 r0w0e0 ad0s8 48423707136 512 3 48423707136 94577553 50318360064 98278047 165 r1w1e2 ad0s7 16000492032 512 2 16000492032 31250961 34317835776 67027023 165 r1w1e1 ad0s6 25724772864 512 1 25724772864 50243697 8593030656 16783263 11 r0w0e0 ad0s5 8592966144 512 0 8592966144 16783137 32256 63 131 SWAP swap 4 r1w1e0 DEV md0 2 r0w0e0 cd0 2 r0w0e0 acd0 2 r0w0e0 ad0s7c 5 r0w0e0 ad0s7a 5 r0w0e0 ad0s8 4 r0w0e0 ad0s7 4 r0w0e0 ad0s6 4 r0w0e0 ad0s5 4 r0w0e0 ad0s2e 4 r0w0e0 ad0s2d 4 r0w0e0 ad0s2c 4 r0w0e0 ad0s2b 4 r0w0e0 ad0s2a 4 r0w0e0 ad0s3 3 r0w0e0 ad0s2 3 r0w0e0 ad0s1 3 r0w0e0 ad0 2 r0w0e0 A non-working kernel(GENERIC): ACD acd0 1 r0w0e0 acd0 8796093020160 2048 FD SWAP swap 4 r1w1e0 DEV ufsid/46387cd73d66d2ca 5 r0w0e0 acd0 2 r0w0e0 ad0s2e 4 r0w0e0 ad0s2d 4 r0w0e0 ad0s2b 4 r0w0e0 ad0s2a 4 r0w0e0 msdosfs/IBM_PRELOAD 4 r0w0e0 ad0s3 3 r0w0e0 ad0s2 3 r0w0e0 ad0s1 3 r0w0e0 ad0 2 r0w0e0 MD PART ad0s2 3 BSD 8 0 16783199 63 16 r3w3e5 r1w1e1 ad0s2e 5841534976 512 5373952 16783199 5 freebsd-ufs 2751463424 5841534976 7 r0w0e0 ad0s2d 201326592 512 4980736 5373951 4 freebsd-ufs 2550136832 201326592 7 r1w1e0 ad0s2b 2147483648 512 786432 4980735 2 freebsd-swap 402653184 2147483648 1 r1w1e1 ad0s2a 402653184 512 0 786431 1 freebsd-ufs 0 402653184 7 ad0 2 MBR 4 63 228338837 63 16 r3w3e8 r0w0e0 ad0s3 98742067200 512 35471520 228327119 3 !15 18161418240 98742067200 15 r3w3e5 ad0s2 8592998400 512 18688320 35471519 2 freebsd 9568419840 8592998400 165 active r0w0e0 ad0s1 9568387584 512 63 18688319 1 !12 32256 9568387584 12 DISK ad0 1 r3w3e8 ad0 116909491200 512 16 63 LABEL ad0s2d 4 r0w0e0 r0w0e0 ufsid/46387cd73d66d2ca 201326592 512 0 201326592 393216 0 0 ad0s1 3 r0w0e0 r0w0e0 msdosfs/IBM_PRELOAD 9568387584 512 0 9568387584 18688257 0 0 VFS ffs.ad0s2e 4 r1w1e1 ffs.ad0s2a 4 r1w1e1 -- Thanks, Tai-hwa Liang From joseph.koshy at gmail.com Thu Apr 2 19:43:07 2009 From: joseph.koshy at gmail.com (Joseph Koshy) Date: Thu Apr 2 19:43:14 2009 Subject: Performance Tools in FreeBSD In-Reply-To: <4451ccf20904010038p64ed2540mec3249f89bb7b8c2@mail.gmail.com> References: <4451ccf20904010038p64ed2540mec3249f89bb7b8c2@mail.gmail.com> Message-ID: <84dead720904021913t1f1c27dasd942c50213e2a83a@mail.gmail.com> > However, PMC seems not to be supported in AMD Opteron CPU because i > get a "invalid arguments" error when > > i use the command pmcstat -S instructions -O . However, > "instructions, cycles,..." are documented in > > pmc manual. By the way, I enable the options in configuration file > options HWPMC_HOOKS and device hwpmc. What kind of CPU do you have? Are there any messages from hwpmc(4) when it initializes? Koshy From lists.br at gmail.com Thu Apr 2 19:44:19 2009 From: lists.br at gmail.com (Luiz Otavio O Souza) Date: Thu Apr 2 20:10:22 2009 Subject: Setting the mss for socket References: <3FD46C21A487490FB15B89E890790121@adnote989><49D4C9A0.9000804@freebsdbrasil.com.br> <49D56212.1000702@sanbe-farma.com> Message-ID: > Patrick Tracanelli wrote: >> Luiz Otavio O Souza escreveu: >>> Hello hackers, >>> >>> Is there a way to set the mss for a socket ? Like you can do in linux >>> with setsockopt(TCP_MAXSEG) ? >>> >>> So i can set the maximum size of packets (or sort of) from a simple >>> userland program. >>> > you mean sysctl -w net.inet.tcp.mssdflt=512 ? Not really... I don't want this to be a system wide option, i need this to be able to generate some traffic under a certain pattern of packet sizes. I really should read the code for more than 30 minutes... it's simple than i first think, i already have a simple patch for this, but it is too ugly for anything more than get iperf running... This is the patch (just for reference - may work for someone else): http://pastebin.com/m706da25b And the iperf patch: http://pastebin.com/m2f8f1100 Luiz From xcllnt at mac.com Thu Apr 2 21:44:10 2009 From: xcllnt at mac.com (Marcel Moolenaar) Date: Thu Apr 2 21:44:17 2009 Subject: Removal of GEOM_BSD, GEOM_MBR, GEOM_PC98 and GEOM_SUNLABEL In-Reply-To: <09040309313414.76643@www.mmlab.cse.yzu.edu.tw> References: <95891.1238477069@critter.freebsd.dk> <20090331133132.1e191836@ernst.jennejohn.org> <20090331155542.74d89d64@ernst.jennejohn.org> <60084D1E-9F64-463A-A8E9-7A237D5C7661@mac.com> <0904011910169.29800@www.mmlab.cse.yzu.edu.tw> <0904020940371.36257@www.mmlab.cse.yzu.edu.tw> <4CCDEFD6-830E-4C8F-B7A2-B7878F8842BE@mac.com> <0904021314574.37737@www.mmlab.cse.yzu.edu.tw> <09040309313414.76643@www.mmlab.cse.yzu.edu.tw> Message-ID: On Apr 2, 2009, at 6:35 PM, Tai-hwa Liang wrote: > On Thu, 2 Apr 2009, Marcel Moolenaar wrote: >> Can you dump the first 2 sectors of slice 3 and >> send it to me: >> dd if=/dev/ad0s3 of=/tmp/dump.dd count=2 bs=512 *snip* > 000001b0 00 00 00 00 00 f2 0e 00 00 00 00 00 00 00 00 01 > |................| > 000001c0 c1 ff 83 ef ff ff 3f 00 00 00 21 17 00 01 00 00 > |......?...!.....| > 000001d0 c1 ff 05 ef ff ff 60 17 00 01 b0 a8 fe 02 00 00 > |......`.........| > 000001e0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > |................| > 000001f0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 55 aa > |..............U.| *snip* It looks like you have a boot menu entry at 0x1b6. Can you try the following patch: Index: g_part_ebr.c =================================================================== --- g_part_ebr.c (revision 190655) +++ g_part_ebr.c (working copy) @@ -403,9 +403,13 @@ if (magic != DOSMAGIC) goto out; - /* The sector is all zeroes, except for the partition entries. */ + /* + * The sector is all zeroes, except for the partition entries + * and a possible IBM Boot Manager menu entry. The menu entry + * is 9 bytes in length and preceeds the partition entries. + */ sum = 0; - for (index = 0; index < DOSPARTOFF; index++) + for (index = 0; index < DOSPARTOFF - 9; index++) sum += buf[index]; if (sum != 0) goto out; The real fix will be a bit more involved, because we should avoid wiping out the boot menu entry on a write. But at least with the patch you should be able to read the EBR. Thanks, -- Marcel Moolenaar xcllnt@mac.com From avatar at mmlab.cse.yzu.edu.tw Thu Apr 2 22:29:56 2009 From: avatar at mmlab.cse.yzu.edu.tw (Tai-hwa Liang) Date: Thu Apr 2 22:30:02 2009 Subject: Removal of GEOM_BSD, GEOM_MBR, GEOM_PC98 and GEOM_SUNLABEL In-Reply-To: References: <95891.1238477069@critter.freebsd.dk> <20090331133132.1e191836@ernst.jennejohn.org> <20090331155542.74d89d64@ernst.jennejohn.org> <60084D1E-9F64-463A-A8E9-7A237D5C7661@mac.com> <0904011910169.29800@www.mmlab.cse.yzu.edu.tw> <0904020940371.36257@www.mmlab.cse.yzu.edu.tw> <4CCDEFD6-830E-4C8F-B7A2-B7878F8842BE@mac.com> <0904021314574.37737@www.mmlab.cse.yzu.edu.tw> <09040309313414.76643@www.mmlab.cse.yzu.edu.tw> Message-ID: <0904031327195.78401@www.mmlab.cse.yzu.edu.tw> On Thu, 2 Apr 2009, Marcel Moolenaar wrote: [...] > It looks like you have a boot menu entry at 0x1b6. Can you > try the following patch: > > Index: g_part_ebr.c > =================================================================== > --- g_part_ebr.c (revision 190655) > +++ g_part_ebr.c (working copy) > @@ -403,9 +403,13 @@ > if (magic != DOSMAGIC) > goto out; > > - /* The sector is all zeroes, except for the partition entries. */ > + /* > + * The sector is all zeroes, except for the partition entries > + * and a possible IBM Boot Manager menu entry. The menu entry > + * is 9 bytes in length and preceeds the partition entries. > + */ > sum = 0; > - for (index = 0; index < DOSPARTOFF; index++) > + for (index = 0; index < DOSPARTOFF - 9; index++) > sum += buf[index]; > if (sum != 0) > goto out; > > > The real fix will be a bit more involved, because we should > avoid wiping out the boot menu entry on a write. But at least > with the patch you should be able to read the EBR. Much better. I can see extended partition nodes after booting with the patched kernel: # ls -la /dev/ad* crw-r----- 1 root operator 0, 73 4 3 21:12 /dev/ad0 crw-r----- 1 root operator 0, 79 4 3 21:12 /dev/ad0s1 crw-r----- 1 root operator 0, 80 4 3 21:12 /dev/ad0s2 crw-r----- 1 root operator 0, 82 4 3 21:12 /dev/ad0s2a crw-r----- 1 root operator 0, 83 4 3 21:12 /dev/ad0s2b crw-r----- 1 root operator 0, 84 4 3 21:12 /dev/ad0s2d crw-r----- 1 root operator 0, 85 4 3 21:12 /dev/ad0s2e crw-r----- 1 root operator 0, 81 4 3 21:12 /dev/ad0s3 crw-r----- 1 root operator 0, 86 4 3 21:12 /dev/ad0s3+00000001 crw-r----- 1 root operator 0, 88 4 3 21:12 /dev/ad0s3+000410a1 crw-r----- 1 root operator 0, 90 4 3 21:12 /dev/ad0s3+00103bf1 crw-r----- 1 root operator 0, 92 4 3 21:12 /dev/ad0s3+0017cda1 lrwxr-xr-x 1 root wheel 14 4 3 21:12 /dev/ad0s5 -> ad0s3+00000001 lrwxr-xr-x 1 root wheel 14 4 3 21:12 /dev/ad0s6 -> ad0s3+000410a1 lrwxr-xr-x 1 root wheel 14 4 3 21:12 /dev/ad0s7 -> ad0s3+00103bf1 lrwxr-xr-x 1 root wheel 14 4 3 21:12 /dev/ad0s8 -> ad0s3+0017cda1 # gpart show => 63 228338775 ad0 MBR (109G) 63 18688257 1 !12 (8.9G) 18688320 16783200 2 freebsd [active] (8.0G) 35471520 192855600 3 !15 (92G) 228327120 11718 - free - (5.7M) => 0 16783200 ad0s2 BSD (8.0G) 0 786432 1 freebsd-ufs (384M) 786432 4194304 2 freebsd-swap (2.0G) 4980736 393216 4 freebsd-ufs (192M) 5373952 11409248 5 freebsd-ufs (5.4G) => 0 192855600 ad0s3 EBR (92G) 0 16783200 1 !131 (8.0G) 16783200 50243760 266401 !11 (24G) 67026960 31251024 1063921 freebsd (15G) 98277984 94577616 1559969 freebsd (45G) The only downside is that I'll have to update /etc/fstab to boot correctly as /dev/ad0s7a is still missing. -- Thanks, Tai-hwa Liang From xcllnt at mac.com Thu Apr 2 23:00:03 2009 From: xcllnt at mac.com (Marcel Moolenaar) Date: Thu Apr 2 23:00:10 2009 Subject: Removal of GEOM_BSD, GEOM_MBR, GEOM_PC98 and GEOM_SUNLABEL In-Reply-To: <0904031327195.78401@www.mmlab.cse.yzu.edu.tw> References: <95891.1238477069@critter.freebsd.dk> <20090331133132.1e191836@ernst.jennejohn.org> <20090331155542.74d89d64@ernst.jennejohn.org> <60084D1E-9F64-463A-A8E9-7A237D5C7661@mac.com> <0904011910169.29800@www.mmlab.cse.yzu.edu.tw> <0904020940371.36257@www.mmlab.cse.yzu.edu.tw> <4CCDEFD6-830E-4C8F-B7A2-B7878F8842BE@mac.com> <0904021314574.37737@www.mmlab.cse.yzu.edu.tw> <09040309313414.76643@www.mmlab.cse.yzu.edu.tw> <0904031327195.78401@www.mmlab.cse.yzu.edu.tw> Message-ID: <8583A3BA-2871-4DF4-9792-1031044A4A22@mac.com> On Apr 2, 2009, at 10:29 PM, Tai-hwa Liang wrote: >> The real fix will be a bit more involved, because we should >> avoid wiping out the boot menu entry on a write. But at least >> with the patch you should be able to read the EBR. > > Much better. I can see extended partition nodes after booting with > the > patched kernel: I dug a bit deeper and it's not a boot manager menu entry, but some signature particular to some tool. I'm not going to worry about preserving that. Patch committed. *snip* > => 0 192855600 ad0s3 EBR (92G) > 0 16783200 1 !131 (8.0G) > 16783200 50243760 266401 !11 (24G) > 67026960 31251024 1063921 freebsd (15G) > 98277984 94577616 1559969 freebsd (45G) > > The only downside is that I'll have to update /etc/fstab to boot > correctly > as /dev/ad0s7a is still missing. Ok, let's look at those sectors as well. Can you send the output of: dd if=/dev/ad0s7 of=dump.dd count=2 bs=512 BTW: Thanks for testing! -- Marcel Moolenaar xcllnt@mac.com From avatar at mmlab.cse.yzu.edu.tw Fri Apr 3 00:18:59 2009 From: avatar at mmlab.cse.yzu.edu.tw (Tai-hwa Liang) Date: Fri Apr 3 00:19:06 2009 Subject: Removal of GEOM_BSD, GEOM_MBR, GEOM_PC98 and GEOM_SUNLABEL In-Reply-To: <8583A3BA-2871-4DF4-9792-1031044A4A22@mac.com> References: <95891.1238477069@critter.freebsd.dk> <20090331133132.1e191836@ernst.jennejohn.org> <20090331155542.74d89d64@ernst.jennejohn.org> <60084D1E-9F64-463A-A8E9-7A237D5C7661@mac.com> <0904011910169.29800@www.mmlab.cse.yzu.edu.tw> <0904020940371.36257@www.mmlab.cse.yzu.edu.tw> <4CCDEFD6-830E-4C8F-B7A2-B7878F8842BE@mac.com> <0904021314574.37737@www.mmlab.cse.yzu.edu.tw> <09040309313414.76643@www.mmlab.cse.yzu.edu.tw> <0904031327195.78401@www.mmlab.cse.yzu.edu.tw> <8583A3BA-2871-4DF4-9792-1031044A4A22@mac.com> Message-ID: <09040315161311.79260@www.mmlab.cse.yzu.edu.tw> On Thu, 2 Apr 2009, Marcel Moolenaar wrote: > > On Apr 2, 2009, at 10:29 PM, Tai-hwa Liang wrote: > >>> The real fix will be a bit more involved, because we should >>> avoid wiping out the boot menu entry on a write. But at least >>> with the patch you should be able to read the EBR. >> >> Much better. I can see extended partition nodes after booting with the >> patched kernel: > > I dug a bit deeper and it's not a boot manager menu entry, > but some signature particular to some tool. I'm not going > to worry about preserving that. > > Patch committed. Thanks! > *snip* >> => 0 192855600 ad0s3 EBR (92G) >> 0 16783200 1 !131 (8.0G) >> 16783200 50243760 266401 !11 (24G) >> 67026960 31251024 1063921 freebsd (15G) >> 98277984 94577616 1559969 freebsd (45G) >> >> The only downside is that I'll have to update /etc/fstab to boot correctly >> as /dev/ad0s7a is still missing. > > Ok, let's look at those sectors as well. Can you send the > output of: > dd if=/dev/ad0s7 of=dump.dd count=2 bs=512 00000000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| * 00000200 57 45 56 82 00 00 00 00 61 6d 6e 65 73 69 61 63 |WEV.....amnesiac| 00000210 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 00000220 00 00 00 00 00 00 00 00 00 02 00 00 3f 00 00 00 |............?...| 00000230 10 00 00 00 1a 79 00 00 f0 03 00 00 11 da dc 01 |.....y..........| 00000240 00 00 00 00 00 00 00 00 10 0e 01 00 00 00 00 00 |................| 00000250 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| * 00000280 00 00 00 00 57 45 56 82 93 e0 08 00 00 20 00 00 |....WEV...... ..| 00000290 00 00 00 00 01 da dc 01 a0 40 1d 02 00 08 00 00 |.........@......| 000002a0 07 08 88 6f 00 00 00 00 00 00 00 00 00 00 00 00 |...o............| 000002b0 00 00 00 00 11 da dc 01 a0 40 1d 02 00 00 00 00 |.........@......| 000002c0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| * 00000400 > BTW: Thanks for testing! Thanks for fixing! :) -- Cheers, Tai-hwa Liang From randy at psg.com Fri Apr 3 00:28:56 2009 From: randy at psg.com (Randy Bush) Date: Fri Apr 3 00:29:02 2009 Subject: zfs chflags References: Message-ID: very up to date 7 i386 system :/usr/src# time make installworld 2>&1 > installworld.log install: /usr/lib/libkse.so.3: chflags: Operation not supported install: /usr/lib/librt.so.1: chflags: Operation not supported chflags: /usr/bin/chpass: Operation not supported install: /usr/bin/login: chflags: Operation not supported install: /usr/bin/opieinfo: chflags: Operation not supported install: /usr/bin/opiepasswd: chflags: Operation not supported chflags: /usr/bin/passwd: Operation not supported install: /usr/bin/rlogin: chflags: Operation not supported install: /usr/bin/rsh: chflags: Operation not supported install: /usr/bin/su: chflags: Operation not supported install: /usr/bin/crontab: chflags: Operation not supported install: /usr/sbin/sliplogin: chflags: Operation not supported shown as "done" on http://wiki.freebsd.org/ZFS, but i think that is only for 8-current, and it does work on my 8-current systems. in the archives, there is a message which says "For the record, defining NO_FSCHG= would work around this." but it does not say what goes to the right of the "=" and may i assume this is to make installworld? so choices seem to be o move to 8-current o dig up some patch to zfs 13 and rebuild o get clue from mailing list randy From Benoit.Calvez at gmail.com Fri Apr 3 02:22:24 2009 From: Benoit.Calvez at gmail.com (Benoit Calvez) Date: Fri Apr 3 02:22:30 2009 Subject: zfs chflags In-Reply-To: References: Message-ID: <3481d8e60904030156n7b77b223p429313b9621f6d95@mail.gmail.com> On Fri, Apr 3, 2009 at 9:28 AM, Randy Bush wrote: > very up to date 7 i386 system > > :/usr/src# time make installworld 2>&1 > installworld.log > install: /usr/lib/libkse.so.3: chflags: Operation not supported > install: /usr/lib/librt.so.1: chflags: Operation not supported > chflags: /usr/bin/chpass: Operation not supported > install: /usr/bin/login: chflags: Operation not supported > install: /usr/bin/opieinfo: chflags: Operation not supported > install: /usr/bin/opiepasswd: chflags: Operation not supported > chflags: /usr/bin/passwd: Operation not supported > install: /usr/bin/rlogin: chflags: Operation not supported > install: /usr/bin/rsh: chflags: Operation not supported > install: /usr/bin/su: chflags: Operation not supported > install: /usr/bin/crontab: chflags: Operation not supported > install: /usr/sbin/sliplogin: chflags: Operation not supported > > shown as "done" on http://wiki.freebsd.org/ZFS, but i think that > is only for 8-current, and it does work on my 8-current systems. > > in the archives, there is a message which says "For the record, defining > NO_FSCHG= would work around this." but it does not say what goes to the > right of the "=" and may i assume this is to make installworld? > > so choices seem to be > o move to 8-current > o dig up some patch to zfs 13 and rebuild > o get clue from mailing list > > randy > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > Yes, it just defines the variables, but the var is empty. -- Benoit C From xcllnt at mac.com Fri Apr 3 08:45:08 2009 From: xcllnt at mac.com (Marcel Moolenaar) Date: Fri Apr 3 08:45:15 2009 Subject: Removal of GEOM_BSD, GEOM_MBR, GEOM_PC98 and GEOM_SUNLABEL In-Reply-To: <09040315161311.79260@www.mmlab.cse.yzu.edu.tw> References: <95891.1238477069@critter.freebsd.dk> <20090331133132.1e191836@ernst.jennejohn.org> <20090331155542.74d89d64@ernst.jennejohn.org> <60084D1E-9F64-463A-A8E9-7A237D5C7661@mac.com> <0904011910169.29800@www.mmlab.cse.yzu.edu.tw> <0904020940371.36257@www.mmlab.cse.yzu.edu.tw> <4CCDEFD6-830E-4C8F-B7A2-B7878F8842BE@mac.com> <0904021314574.37737@www.mmlab.cse.yzu.edu.tw> <09040309313414.76643@www.mmlab.cse.yzu.edu.tw> <0904031327195.78401@www.mmlab.cse.yzu.edu.tw> <8583A3BA-2871-4DF4-9792-1031044A4A22@mac.com> <09040315161311.79260@www.mmlab.cse.yzu.edu.tw> Message-ID: <1DDB4728-7742-4265-999F-F1A0FC69F9E4@mac.com> On Apr 3, 2009, at 12:18 AM, Tai-hwa Liang wrote: >> Ok, let's look at those sectors as well. Can you send the >> output of: >> dd if=/dev/ad0s7 of=dump.dd count=2 bs=512 > > 00000000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > |................| > * > 00000200 57 45 56 82 00 00 00 00 61 6d 6e 65 73 69 61 63 | > WEV.....amnesiac| > 00000210 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > |................| > 00000220 00 00 00 00 00 00 00 00 00 02 00 00 3f 00 00 00 > |............?...| > 00000230 10 00 00 00 1a 79 00 00 f0 03 00 00 11 da dc 01 > |.....y..........| > 00000240 00 00 00 00 00 00 00 00 10 0e 01 00 00 00 00 00 > |................| > 00000250 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > |................| > * > 00000280 00 00 00 00 57 45 56 82 93 e0 08 00 00 20 00 00 > |....WEV...... ..| > 00000290 00 00 00 00 01 da dc 01 a0 40 1d 02 00 08 00 00 > |.........@......| > 000002a0 07 08 88 6f 00 00 00 00 00 00 00 00 00 00 00 00 > |...o............| > 000002b0 00 00 00 00 11 da dc 01 a0 40 1d 02 00 00 00 00 > |.........@......| > 000002c0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > |................| > * > 00000400 Hmmmm... I don't think there's anything wrong with the label nor the code. If the label is rejected, the dmesg should show that. Is there anything in the dmesg like? GEOM: ad0s3+00103bf1: invalid disklabel. Also, could you trigger a re-taste by writing all zeroes to the first sector: dd if=/dev/zero of=/dev/ad0s7 count=1 bs=512 Thanks, -- Marcel Moolenaar xcllnt@mac.com From avatar at mmlab.cse.yzu.edu.tw Fri Apr 3 18:08:24 2009 From: avatar at mmlab.cse.yzu.edu.tw (Tai-hwa Liang) Date: Fri Apr 3 18:08:31 2009 Subject: Removal of GEOM_BSD, GEOM_MBR, GEOM_PC98 and GEOM_SUNLABEL In-Reply-To: <1DDB4728-7742-4265-999F-F1A0FC69F9E4@mac.com> References: <95891.1238477069@critter.freebsd.dk> <20090331133132.1e191836@ernst.jennejohn.org> <20090331155542.74d89d64@ernst.jennejohn.org> <60084D1E-9F64-463A-A8E9-7A237D5C7661@mac.com> <0904011910169.29800@www.mmlab.cse.yzu.edu.tw> <0904020940371.36257@www.mmlab.cse.yzu.edu.tw> <4CCDEFD6-830E-4C8F-B7A2-B7878F8842BE@mac.com> <0904021314574.37737@www.mmlab.cse.yzu.edu.tw> <09040309313414.76643@www.mmlab.cse.yzu.edu.tw> <0904031327195.78401@www.mmlab.cse.yzu.edu.tw> <8583A3BA-2871-4DF4-9792-1031044A4A22@mac.com> <09040315161311.79260@www.mmlab.cse.yzu.edu.tw> <1DDB4728-7742-4265-999F-F1A0FC69F9E4@mac.com> Message-ID: <0904040858433.86299@www.mmlab.cse.yzu.edu.tw> On Fri, 3 Apr 2009, Marcel Moolenaar wrote: [...] > Hmmmm... I don't think there's anything wrong with the label > nor the code. If the label is rejected, the dmesg should show > that. Is there anything in the dmesg like? > GEOM: ad0s3+00103bf1: invalid disklabel. # dmesg | grep GEOM GEOM: new disk cd0 GEOM_LABEL: Label ufsid/46387cd616292ca8 removed. GEOM_LABEL: Label for provider ad0s2a is ufsid/46387cd616292ca8. GEOM_LABEL: Label ufsid/46387cd73d66d2ca removed. GEOM_LABEL: Label for provider ad0s2d is ufsid/46387cd73d66d2ca. GEOM_LABEL: Label ufsid/46387cd6c10fa381 removed. GEOM_LABEL: Label for provider ad0s2e is ufsid/46387cd6c10fa381. GEOM_LABEL: Label ufsid/46389322544a8c64 removed. GEOM_LABEL: Label for provider ad0s3+00103bf1a is ufsid/46389322544a8c64. GEOM_LABEL: Label ufsid/46387cd616292ca8 removed. GEOM_LABEL: Label ufsid/46387cd73d66d2ca removed. GEOM_LABEL: Label ufsid/46387cd6c10fa381 removed. GEOM_LABEL: Label ufsid/46389322544a8c64 removed. GEOM_LABEL: Label for provider md0 is ufsid/49d71e25191c321d. GEOM_LABEL: Label ufsid/49d71e25191c321d removed. > Also, could you trigger a re-taste by writing all zeroes to > the first sector: > dd if=/dev/zero of=/dev/ad0s7 count=1 bs=512 # dd if=/dev/zero of=/dev/ad0s7 bs=512 count=1 dd: /dev/ad0s7: Operation not permitted # sysctl kern.geom.debugflags=16 kern.geom.debugflags: 0 -> 16 # dd if=/dev/zero of=/dev/ad0s7 bs=512 count=1 dd: /dev/ad0s7: Operation not permitted # I can see ad0s3 falls in 'scheme: EBR' but not 'BSD scheme' now: Geom name: ad0 fwheads: 16 fwsectors: 63 last: 228338837 first: 63 entries: 4 scheme: MBR Providers: 1. Name: ad0s1 Mediasize: 9568387584 (8.9G) Sectorsize: 512 Mode: r0w0e0 rawtype: 12 length: 9568387584 offset: 32256 type: !12 index: 1 end: 18688319 start: 63 2. Name: ad0s2 Mediasize: 8592998400 (8.0G) Sectorsize: 512 Mode: r4w4e7 attrib: active rawtype: 165 length: 8592998400 offset: 9568419840 type: freebsd index: 2 end: 35471519 start: 18688320 3. Name: ad0s3 Mediasize: 98742067200 (92G) Sectorsize: 512 Mode: r1w1e2 rawtype: 15 length: 98742067200 offset: 18161418240 type: !15 index: 3 end: 228327119 start: 35471520 Consumers: 1. Name: ad0 Mediasize: 116909491200 (109G) Sectorsize: 512 Mode: r5w5e14 Geom name: ad0s2 fwheads: 16 fwsectors: 63 last: 16783199 first: 0 entries: 8 scheme: BSD Providers: 1. Name: ad0s2a Mediasize: 402653184 (384M) Sectorsize: 512 Mode: r1w1e1 rawtype: 7 length: 402653184 offset: 0 type: freebsd-ufs index: 1 end: 786431 start: 0 2. Name: ad0s2b Mediasize: 2147483648 (2.0G) Sectorsize: 512 Mode: r1w1e0 rawtype: 1 length: 2147483648 offset: 402653184 type: freebsd-swap index: 2 end: 4980735 start: 786432 3. Name: ad0s2d Mediasize: 201326592 (192M) Sectorsize: 512 Mode: r1w1e1 rawtype: 7 length: 201326592 offset: 2550136832 type: freebsd-ufs index: 4 end: 5373951 start: 4980736 4. Name: ad0s2e Mediasize: 5841534976 (5.4G) Sectorsize: 512 Mode: r1w1e1 rawtype: 7 length: 5841534976 offset: 2751463424 type: freebsd-ufs index: 5 end: 16783199 start: 5373952 Consumers: 1. Name: ad0s2 Mediasize: 8592998400 (8.0G) Sectorsize: 512 Mode: r4w4e7 Geom name: ad0s3 fwheads: 16 fwsectors: 63 last: 192855599 first: 0 entries: 3061200 scheme: EBR Providers: 1. Name: ad0s3+00000001 Mediasize: 8592966144 (8.0G) Sectorsize: 512 Mode: r0w0e0 rawtype: 131 length: 8592966144 offset: 32256 type: !131 index: 1 end: 16783199 start: 0 2. Name: ad0s3+000410a1 Mediasize: 25724772864 (24G) Sectorsize: 512 Mode: r0w0e0 rawtype: 11 length: 25724772864 offset: 8593030656 type: !11 index: 266401 end: 67026959 start: 16783200 3. Name: ad0s3+00103bf1 Mediasize: 16000492032 (15G) Sectorsize: 512 Mode: r1w1e1 rawtype: 165 length: 16000492032 offset: 34317835776 type: freebsd index: 1063921 end: 98277983 start: 67026960 4. Name: ad0s3+0017cda1 Mediasize: 48423707136 (45G) Sectorsize: 512 Mode: r0w0e0 rawtype: 165 length: 48423707136 offset: 50318360064 type: freebsd index: 1559969 end: 192855599 start: 98277984 Consumers: 1. Name: ad0s3 Mediasize: 98742067200 (92G) Sectorsize: 512 Mode: r1w1e2 -- Cheers, Tai-hwa Liang From xcllnt at mac.com Fri Apr 3 18:23:39 2009 From: xcllnt at mac.com (Marcel Moolenaar) Date: Fri Apr 3 18:23:45 2009 Subject: Removal of GEOM_BSD, GEOM_MBR, GEOM_PC98 and GEOM_SUNLABEL In-Reply-To: <0904040858433.86299@www.mmlab.cse.yzu.edu.tw> References: <95891.1238477069@critter.freebsd.dk> <20090331133132.1e191836@ernst.jennejohn.org> <20090331155542.74d89d64@ernst.jennejohn.org> <60084D1E-9F64-463A-A8E9-7A237D5C7661@mac.com> <0904011910169.29800@www.mmlab.cse.yzu.edu.tw> <0904020940371.36257@www.mmlab.cse.yzu.edu.tw> <4CCDEFD6-830E-4C8F-B7A2-B7878F8842BE@mac.com> <0904021314574.37737@www.mmlab.cse.yzu.edu.tw> <09040309313414.76643@www.mmlab.cse.yzu.edu.tw> <0904031327195.78401@www.mmlab.cse.yzu.edu.tw> <8583A3BA-2871-4DF4-9792-1031044A4A22@mac.com> <09040315161311.79260@www.mmlab.cse.yzu.edu.tw> <1DDB4728-7742-4265-999F-F1A0FC69F9E4@mac.com> <0904040858433.86299@www.mmlab.cse.yzu.edu.tw> Message-ID: <7AD352A2-BEDD-4DFD-896D-104E6376D887@mac.com> On Apr 3, 2009, at 6:08 PM, Tai-hwa Liang wrote: > # dmesg | grep GEOM > GEOM: new disk cd0 > GEOM_LABEL: Label ufsid/46387cd616292ca8 removed. > GEOM_LABEL: Label for provider ad0s2a is ufsid/46387cd616292ca8. > GEOM_LABEL: Label ufsid/46387cd73d66d2ca removed. > GEOM_LABEL: Label for provider ad0s2d is ufsid/46387cd73d66d2ca. > GEOM_LABEL: Label ufsid/46387cd6c10fa381 removed. > GEOM_LABEL: Label for provider ad0s2e is ufsid/46387cd6c10fa381. > GEOM_LABEL: Label ufsid/46389322544a8c64 removed. > GEOM_LABEL: Label for provider ad0s3+00103bf1a is ufsid/ > 46389322544a8c64. Hmm... the BSD scheme does probe and read. You have partition 'a' under ad0s3+00103bf1 here. It looks like the partition gets spoiled shortly after. Can you enable tracing and check if that's the case? > I can see ad0s3 falls in 'scheme: EBR' but not 'BSD scheme' now: That's correct. ad0s3 is an extended partition. -- Marcel Moolenaar xcllnt@mac.com From avatar at mmlab.cse.yzu.edu.tw Fri Apr 3 20:15:27 2009 From: avatar at mmlab.cse.yzu.edu.tw (Tai-hwa Liang) Date: Fri Apr 3 20:15:34 2009 Subject: Removal of GEOM_BSD, GEOM_MBR, GEOM_PC98 and GEOM_SUNLABEL In-Reply-To: <7AD352A2-BEDD-4DFD-896D-104E6376D887@mac.com> References: <95891.1238477069@critter.freebsd.dk> <20090331133132.1e191836@ernst.jennejohn.org> <20090331155542.74d89d64@ernst.jennejohn.org> <60084D1E-9F64-463A-A8E9-7A237D5C7661@mac.com> <0904011910169.29800@www.mmlab.cse.yzu.edu.tw> <0904020940371.36257@www.mmlab.cse.yzu.edu.tw> <4CCDEFD6-830E-4C8F-B7A2-B7878F8842BE@mac.com> <0904021314574.37737@www.mmlab.cse.yzu.edu.tw> <09040309313414.76643@www.mmlab.cse.yzu.edu.tw> <0904031327195.78401@www.mmlab.cse.yzu.edu.tw> <8583A3BA-2871-4DF4-9792-1031044A4A22@mac.com> <09040315161311.79260@www.mmlab.cse.yzu.edu.tw> <1DDB4728-7742-4265-999F-F1A0FC69F9E4@mac.com> <0904040858433.86299@www.mmlab.cse.yzu.edu.tw> <7AD352A2-BEDD-4DFD-896D-104E6376D887@mac.com> Message-ID: <09040411131618.87313@www.mmlab.cse.yzu.edu.tw> On Fri, 3 Apr 2009, Marcel Moolenaar wrote: [...] > Hmm... the BSD scheme does probe and read. You have > partition 'a' under ad0s3+00103bf1 here. It looks > like the partition gets spoiled shortly after. > > Can you enable tracing and check if that's the case? boot with kern.geom.debugflags=1: Copyright (c) 1992-2009 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 is a registered trademark of The FreeBSD Foundation. FreeBSD 8.0-CURRENT #46: Sat Apr 4 08:25:53 CST 2009 [...] pnpbios: Event flag at 4b4 Other BIOS signatures found: g_ignition g_modevent(DISK, LOAD) g_post_event_x(0xc04cd490, 0xc38060a0, 2, 0) g_modevent(PART, LOAD) g_post_event_x(0xc04cd490, 0xc3806090, 2, 0) g_modevent(DEV, LOAD) g_post_event_x(0xc04cd490, 0xc3806080, 2, 0) wlan: <802.11 Link Layer> snd_unit_init() u=0x00ff8000 [512] d=0x00007c00 [32] c=0x000003ff [1024] feeder_register: snd_unit=-1 snd_maxautovchans=16 latency=5 feeder_buffersize=16384 feeder_rate_min=1 feeder_rate_max=2016000 feeder_rate_round=25 g_modevent(VFS, LOAD) g_post_event_x(0xc04cd490, 0xc3806040, 2, 0) g_modevent(SWAP, LOAD) g_post_event_x(0xc04cd490, 0xc3806030, 2, 0) g_modevent(LABEL, LOAD) g_post_event_x(0xc04cd490, 0xc3806020, 2, 0) random: g_modevent(ACD, LOAD) g_post_event_x(0xc04cd490, 0xc3806590, 2, 0) io: mem: Pentium Pro MTRR support enabled null: crypto: g_post_event_x(0xc04cd2c0, 0xc38e5a00, 2, 0) g_post_event_x(0xc04cd2c0, 0xc38e59f0, 2, 0) g_post_event_x(0xc04cd2c0, 0xc38e5820, 2, 0) g_post_event_x(0xc04cd2c0, 0xc38e5700, 2, 0) ACPI: RSDP @ 0x0xf6d70/0x0024 (v 2 IBM ) [...] ata0: Identifying devices: 00000001 ata0: New devices: 00000001 g_load_class(DISK) g_load_class(PART) g_load_class(DEV) g_load_class(VFS) g_load_class(SWAP) g_load_class(LABEL) g_load_class(ACD) g_retaste(PART) g_retaste(PART)usbus0: 12Mbps Full Speed USB v1.0 usbus1: 12Mbps Full Speed USB v1.0 usbus2: 12Mbps Full Speed USB v1.0 usbus3: 480Mbps High Speed USB v2.0 ata0-master: pio=PIO4 wdma=WDMA2 udma=UDMA100 cable=80 wire g_retaste(PART) g_retaste(PART)ad0: setting PIO4 on ICH4 chip battery0: battery initiaad0: setting UDMA100 on ICH4 chip lization start acpi_acadad0: 111493MB at ata0-master UDMA100 ad0: 228338850 sectors [226526C/16H/63S] 16 sectors/interrupt 1 depth queue g_post_event_x(0xc04c78b0, 0xc39e4c00, 2, 0) ref 0xc39e4c00 g_post_event_x(0xc04cb510, 0xc384ca00, 2, 0) ref 0xc384ca00 ref 0xc384c980 GEOM: new disk ad0 g_label_taste(LABEL, ad0) 0: acline initialization start ata1: Identifying devices: 00030000 ata1: New devices: 00030000 ata1-master: pio=PIO4 wdma=WDMA2 udma=UDMA33 cable=40 wire battery0: battery initialization done, tried 1 times acpi_acad0: On Line acpi_acad0: acline initialization done, tried 1 times ugen0.1: at usbus0 uhub0: on usbus0 ugen1.1: at usbus1 uhub1: on usbus1 ugen2.1: at usbus2 uhub2: on usbus2 ugen3.1: at usbus3 uhub3: on usbus3 g_detach(0xc3adcdc0) g_destroy_consumer(0xc3adcdc0) g_destroy_geom(0xc388a280(label:taste)) dev_taste(DEV,ad0) g_part_taste(PART,ad0) g_post_event_x(0xc04cb510, 0xc39a8a80, 2, 0) ref 0xc39a8a80 ref 0xc3ae0000 g_post_event_x(0xc04cb510, 0xc3ae0500, 2, 0) ref 0xc3ae0500 ref 0xc3ae0000 g_post_event_x(0xc04cb510, 0xc39a8d80, 2, 0) ref 0xc39a8d80 ref 0xc3ae0000 g_label_taste(LABEL, ad0s1) g_slice_config(ad0s1, 0, 1) g_post_event_x(0xc04cb510, 0xc388a280, 2, 0) ref 0xc388a280 ref 0xc384cb00 GEOM_LABEL: Label for provider ad0s1 is msdosfs/IBM_PRELOAD. g_detach(0xc3addc80) g_destroy_consumer(0xc3addc80) g_destroy_geom(0xc384ca80(label:taste)) dev_taste(DEV,ad0s1) g_part_taste(PART,ad0s1) g_wither_geom(0xc3ae4700(ad0s1)) g_label_taste(LABEL, ad0s2) g_detach(0xc3addb00) g_destroy_consumer(0xc3addb00) g_destroy_geom(0xc3ae4600(label:taste)) dev_taste(DEV,ad0s2) g_part_taste(PART,ad0s2) g_post_event_x(0xc04cb510, 0xc3ae4400, 2, 0) ref 0xc3ae4400 ref 0xc3ae4500 g_post_event_x(0xc04cb510, 0xc3ae4300, 2, 0) ref 0xc3ae4300 ref 0xc3ae4500 g_post_event_x(0xc04cb510, 0xc3ae4200, 2, 0) ref 0xc3ae4200 ref 0xc3ae4500 g_post_event_x(0xc04cb510, 0xc3ae4100, 2, 0) ref 0xc3ae4100 ref 0xc3ae4500 g_label_taste(LABEL, ad0s3) g_detach(0xc3add880) g_destroy_consumer(0xc3add880) g_destroy_geom(0xc3ae4000(label:taste)) dev_taste(DEV,ad0s3) g_part_taste(PART,ad0s3) g_post_event_x(0xc04cb510, 0xc3ae0d00, 2, 0) ref 0xc3ae0d00 ref 0xc3ae0e00 g_post_event_x(0xc04cb510, 0xc3ae0c00, 2, 0) ref 0xc3ae0c00 ref 0xc3ae0e00 g_post_event_x(0xc04cb510, 0xc3ae0b00, 2, 0) ref 0xc3ae0b00 ref 0xc3ae0e00 g_post_event_x(0xc04cb510, 0xc3ae0a00, 2, 0) ref 0xc3ae0a00 ref 0xc3ae0e00 g_label_taste(LABEL, msdosfs/IBM_PRELOAD) dev_taste(DEV,msdosfs/IBM_PRELOAD) g_part_taste(PART,msdosfs/IBM_PRELOAD) g_wither_geom(0xc3ae0800(msdosfs/IBM_PRELOAD)) g_label_taste(LABEL, ad0s2a) g_slice_config(ad0s2a, 0, 1) g_post_event_x(0xc04cb510, 0xc3ae0700, 2, 0) ref 0xc3ae0700 ref 0xc3ae0780 GEOM_LABEL: Label for provider ad0s2a is ufsid/46387cd616292ca8. g_detach(0xc3add580) g_destroy_consumer(0xc3add580) g_destroy_geom(0xc3ae4800(label:taste)) dev_taste(DEV,ad0s2a) g_part_taste(PART,ad0s2a) g_wither_geom(0xc39a8700(ad0s2a)) g_label_taste(LABEL, ad0s2b) g_detach(0xc3add440) g_destroy_consumer(0xc3add440) g_destroy_geom(0xc3ae4600(label:taste)) dev_taste(DEV,ad0s2b) g_part_taste(PART,ad0s2b) g_wither_geom(0xc3ae4680(ad0s2b)) g_label_taste(LABEL, ad0s2d) g_slice_config(ad0s2d, 0, 1) g_post_event_x(0xc04cb510, 0xc3ae4600, 2, 0) ref 0xc3ae4600 ref 0xc3ae4280 GEOM_LABEL: Label for provider ad0s2d is ufsid/46387cd73d66d2ca. g_detach(0xc3add340) g_destroy_consumer(0xc3add340) g_destroy_geom(0xc384ca80(label:taste)) dev_taste(DEV,ad0s2d) g_part_taste(PART,ad0s2d) g_wither_geom(0xc384ca80(ad0s2d)) g_label_taste(LABEL, ad0s2e) g_slice_config(ad0s2e, 0, 1) g_post_event_x(0xc04cb510, 0xc3af3880, 2, 0) ref 0xc3af3880 ref 0xc3af3900 GEOM_LABEL: Label for provider ad0s2e is ufsid/46387cd6c10fa381. g_detach(0xc3add200) g_destroy_consumer(0xc3add200) g_destroy_geom(0xc3ae4180(label:taste)) dev_taste(DEV,ad0s2e) g_part_taste(PART,ad0s2e) g_wither_geom(0xc3af3700(ad0s2e)) g_label_taste(LABEL, ad0s3+00000001) g_detach(0xc3add0c0) g_destroy_consumer(0xc3add0c0) g_destroy_geom(0xc3af3680(label:taste)) dev_taste(DEV,ad0s3+00000001) g_part_taste(PART,ad0s3+00000001) g_wither_geom(0xc3af3580(ad0s3+00000001)) g_label_taste(LABEL, ad0s3+000410a1) g_slice_config(ad0s3+000410a1, 0, 1) g_post_event_x(0xc04cb510, 0xc3af3380, 2, 0) ref 0xc3af3380 ref 0xc3af3400 GEOM_LABEL: Label for provider ad0s3+000410a1 is msdosfs/ . g_detach(0xc3add440) g_destroy_consumer(0xc3add440) g_destroy_geom(0xc3af3480(label:taste)) dev_taste(DEV,ad0s3+000410a1) g_part_taste(PART,ad0s3+000410a1) g_wither_geom(0xc3af3200(ad0s3+000410a1)) g_label_taste(LABEL, ad0s3+00103bf1) g_detach(0xc3addc80) g_destroy_consumer(0xc3addc80) g_destroy_geom(0xc3af3100(label:taste)) dev_taste(DEV,ad0s3+00103bf1) g_part_taste(PART,ad0s3+00103bf1) g_post_event_x(0xc04cb510, 0xc3ae4e00, 2, 0) ref 0xc3ae4e00 ref 0xc3af3000 g_label_taste(LABEL, ad0s3+0017cda1) g_detach(0xc3af6280) g_destroy_consumer(0xc3af6280) g_destroy_geom(0xc3ae4d00(label:taste)) dev_taste(DEV,ad0s3+0017cda1) g_part_taste(PART,ad0s3+0017cda1) g_wither_geom(0xc3ae4c00(ad0s3+0017cda1)) g_label_taste(LABEL, ufsid/46387cd616292ca8) dev_taste(DEV,ufsid/46387cd616292ca8) g_part_taste(PART,ufsid/46387cd616292ca8) g_wither_geom(0xc3ae4a00(ufsid/46387cd616292ca8)) g_label_taste(LABEL, ufsid/46387cd73d66d2ca) dev_taste(DEV,ufsid/46387cd73d66d2ca) g_part_taste(PART,ufsid/46387cd73d66d2ca) g_wither_geom(0xc3ae4880(ufsid/46387cd73d66d2ca)) g_label_taste(LABEL, ufsid/46387cd6c10fa381) dev_taste(DEV,ufsid/46387cd6c10fa381) g_part_taste(PART,ufsid/46387cd6c10fa381) g_wither_geom(0xc3ae0980(ufsid/46387cd6c10fa381)) g_label_taste(LABEL, msdosfs/ ) dev_taste(DEV,msdosfs/ ) g_part_taste(PART,msdosfs/ ) g_wither_geom(0xc3ae4d00(msdosfs/ )) g_label_taste(LABEL, ad0s3+00103bf1a) g_slice_config(ad0s3+00103bf1a, 0, 1) g_post_event_x(0xc04cb510, 0xc3af3180, 2, 0) ref 0xc3af3180 ref 0xc3ae0b80 GEOM_LABEL: Label for provider ad0s3+00103bf1a is ufsid/46389322544a8c64. g_detach(0xc3ae2d40) g_destroy_consumer(0xc3ae2d40) g_destroy_geom(0xc3af3100(label:taste)) dev_taste(DEV,ad0s3+00103bf1a) g_part_taste(PART,ad0s3+00103bf1a) g_wither_geom(0xc3af3500(ad0s3+00103bf1a)) g_label_taste(LABEL, ufsid/46389322544a8c64) dev_taste(DEV,ufsid/46389322544a8c64) g_part_taste(PART,ufsid/46389322544a8c64) g_wither_geom(0xc3ae4180(ufsid/46389322544a8c64)) g_detach(0xc3ae2bc0) g_destroy_consumer(0xc3ae2bc0) g_destroy_geom(0xc3ae4180(ufsid/46389322544a8c64)) g_detach(0xc3ae2c40) g_destroy_consumer(0xc3ae2c40) g_destroy_geom(0xc3af3500(ad0s3+00103bf1a)) g_detach(0xc3ae2dc0) g_destroy_consumer(0xc3ae2dc0) g_destroy_geom(0xc3ae4d00(msdosfs/ )) g_detach(0xc3ae2e80) g_destroy_consumer(0xc3ae2e80) g_destroy_geom(0xc3ae0980(ufsid/46387cd6c10fa381)) g_detach(0xc3af6040) g_destroy_consumer(0xc3af6040) g_destroy_geom(0xc3ae4880(ufsid/46387cd73d66d2ca)) g_detach(0xc3af60c0) g_destroy_consumer(0xc3af60c0) g_destroy_geom(0xc3ae4a00(ufsid/46387cd616292ca8)) g_detach(0xc3af6180) g_destroy_consumer(0xc3af6180) g_destroy_geom(0xc3ae4c00(ad0s3+0017cda1)) g_detach(0xc3addb00) g_destroy_consumer(0xc3addb00) g_destroy_geom(0xc3af3200(ad0s3+000410a1)) g_detach(0xc3add200) g_destroy_consumer(0xc3add200) g_destroy_geom(0xc3af3580(ad0s3+00000001)) g_detach(0xc3add100) g_destroy_consumer(0xc3add100) g_destroy_geom(0xc3af3700(ad0s2e)) g_detach(0xc3add240) g_destroy_consumer(0xc3add240) g_destroy_geom(0xc384ca80(ad0s2d)) g_detach(0xc3add380) g_destroy_consumer(0xc3add380) g_destroy_geom(0xc3ae4680(ad0s2b)) g_detach(0xc3add480) g_destroy_consumer(0xc3add480) g_destroy_geom(0xc39a8700(ad0s2a)) g_detach(0xc3add600) g_destroy_consumer(0xc3add600) g_destroy_geom(0xc3ae0800(msdosfs/IBM_PRELOAD)) g_detach(0xc3addb80) g_destroy_consumer(0xc3addb80) g_destroy_geom(0xc3ae4700(ad0s1)) uhub0: 2 ports with 2 removable, self powered uhub1: 2 ports with 2 removable, self powered uhub2: 2 ports with 2 removable, self powered ata1: reiniting channel .. ata1: reset tp1 mask=03 ostat0=50 ostat1=00 ata1: stat0=0x00 err=0x01 lsb=0x14 msb=0xeb ata1: stat1=0x00 err=0x01 lsb=0x14 msb=0xeb ata1: reset tp2 stat0=00 stat1=00 devices=0x30000 ata1: reinit done .. unknown: FAILURE - ATAPI_IDENTIFY timed out LBA=0 ata1: reiniting channel .. ata1: reset tp1 mask=03 ostat0=00 ostat1=00 ata1: stat0=0x00 err=0x01 lsb=0x14 msb=0xeb ata1: stat1=0x00 err=0x01 lsb=0x14 msb=0xeb ata1: reset tp2 stat0=00 stat1=00 devices=0x30000 ata1: reinit done .. unknown: FAILURE - ATAPI_IDENTIFY timed out LBA=0 acd0: setting PIO4 on ICH4 chip acd0: setting UDMA33 on ICH4 chip g_post_event_x(0xc04863d0, 0xc3ae0680, 2, 0) acd0: CDRW drive at ata1 as master acd0: read 4134KB/s (4134KB/s) write 2755KB/s (2755KB/s), 2048KB buffer, UDMA33 acd0: Reads: CDR, CDRW, CDDA stream, DVDROM, DVDR, DVDRAM, packet acd0: Writes: CDR, CDRW, test write, burnproof acd0: Audio: play, 256 volume levels acd0: Mechanism: ejectable tray, unlocked acd0: Medium: no/blank disc g_post_event_x(0xc04cb510, 0xc384ca80, 2, 0) ref 0xc384ca80 ref 0xc3ae4680 g_label_taste(LABEL, acd0) acd0: FAILURE - INQUIRY ILLEGAL REQUEST asc=0x24 ascq=0x00 sks=0x40 0x00 0x01 (probe0:ata1:0:0:0): error 22 (probe0:ata1:0:0:0): Unretryable Error (probe0:ata1:0:0:0): Down reving Protocol Version from 2 to 0? (probe0:ata1:0:0:0): TEST UNIT READY. CDB: 0 0 0 0 0 0 (probe0:ata1:0:0:0): CAM Status: SCSI Status Error (probe0:ata1:0:0:0): SCSI Status: Check Condition (probe0:ata1:0:0:0): NOT READY asc:3a,1 (probe0:ata1:0:0:0): Medium not present - tray closed (probe0:ata1:0:0:0): (probe0:ata1:0:0:0): TEST UNIT READY. CDB: 0 0 0 0 0 0 (probe0:ata1:0:0:0): NOT READY asc:3a,1 (probe0:ata1:0:0:0): Medium not present - tray closed Unretryable error (probe0:ata1:0:0:0): error 6 (probe0:ata1:0:0:0): Unretryable Error pcm0: measured ac97 link rate at 3996 Hz (probe0:ata1:0:0:0): error 6 (probe0:ata1:0:0:0): Unretryable Error g_detach(0xc3ae25c0) g_destroy_consumer(0xc3ae25c0) g_destroy_geom(0xc3af3580(label:taste)) dev_taste(DEV,acd0) g_part_taste(PART,acd0) acd0: FAILURE - INQUIRY ILLEGAL REQUEST asc=0x24 ascq=0x00 sks=0x40 0x00 0x01 (probe0:ata1:0:0:0): error 22 (probe0:ata1:0:0:0): Unretryable Error pass0 at ata1 bus 0 target 0 lun 0 pass0: Removable CD-ROM SCSI-0 device pass0: 33.000MB/s transfers g_post_event_x(0xc04c78b0, 0xc3af9400, 2, 0) ref 0xc3af9400 (cd0:ata1:0:0:0): error 6 (cd0:ata1:0:0:0): Unretryable Error cd0 at ata1 bus 0 target 0 lun 0 cd0: Removable CD-ROM SCSI-0 device cd0: 33.000MB/s transfers cd0: Attempt to query device size failed: NOT READY, Medium not present - tray closed g_wither_geom(0xc3ae4c00(acd0)) g_post_event_x(0xc04cb510, 0xc3af3480, 2, 0) ref 0xc3af3480 ref 0xc3ae4180 GEOM: new disk cd0 g_label_taste(LABEL, cd0) (cd0:ata1:0:0:0): error 6 (cd0:ata1:0:0:0): Unretryable Error g_detach(0xc3add100) g_destroy_consumer(0xc3add100) g_destroy_geom(0xc3af3100(label:taste)) dev_taste(DEV,cd0) scsi_cd.c::ioctl cmd=4400648b error=25 g_part_taste(PART,cd0) (cd0:ata1:0:0:0): error 6 (cd0:ata1:0:0:0): Unretryable Error g_wither_geom(0xc3ae0a80(cd0)) g_detach(0xc3ae2e80) g_destroy_consumer(0xc3ae2e80) g_destroy_geom(0xc3ae0a80(cd0)) g_detach(0xc39b5280) g_destroy_consumer(0xc39b5280) g_destroy_geom(0xc3ae4c00(acd0)) Root mount waiting for: usbus3 uhub3: 6 ports with 6 removable, self powered Trying to mount root from ufs:/dev/ad0s2a ct_to_ts([2009-04-04 11:06:51]) = 1238843211.000000000 start_init: trying /sbin/init g_disk_kernedump(ad0, 9971073024, 2147483648) Entropy harvesting: interrupts ethernet point_to_point g_post_event_x(0xc04c7590, 0xc3ae3960, 2, 262144) g_post_event_x(0xc04c7590, 0xc3ae3940, 2, 262144) g_post_event_x(0xc04c8a00, 0xc3ae3980, 2, 262144) g_post_event_x(0xc04c8a00, 0xc3ae39c0, 2, 262144) g_post_event_x(0xc04c8880, 0xc3ae3a20, 2, 262144) g_post_event_x(0xc04c8880, 0xc3ae3a40, 2, 262144) g_post_event_x(0xc04c8840, 0xc3ae3a60, 2, 262144) g_post_event_x(0xc04c8840, 0xc3ae3a80, 2, 262144) kickstart . g_post_event_x(0xc0665230, 0xdf0d3c64, 2, 262144) g_post_event_x(0xc04cb710, 0xc384ca00, 2, 0) ref 0xc384ca00 g_post_event_x(0xc04cb710, 0xc3ae0500, 2, 0) ref 0xc3ae0500 g_post_event_x(0xc04cb710, 0xc3ae4300, 2, 0) ref 0xc3ae4300 g_post_event_x(0xc04cb710, 0xc3ae4400, 2, 0) ref 0xc3ae4400 GEOM_LABEL: Label ufsid/46387cd616292ca8 removed. g_slice_spoiled(0xc3add540/ad0s2a) g_wither_geom(0xc3ae0780(ad0s2a)) g_orphan_provider(0xc3ae0700(ufsid/46387cd616292ca8), 6) g_orphan_register(ufsid/46387cd616292ca8) g_dev_orphan(0xc3af6100(ufsid/46387cd616292ca8)) g_detach(0xc3af6100) g_destroy_consumer(0xc3af6100) g_destroy_geom(0xc3ae4b00(ufsid/46387cd616292ca8)) g_detach(0xc3add540) g_destroy_consumer(0xc3add540) g_destroy_geom(0xc3ae0780(ad0s2a)) /dev/ad0s2a: FILE SYSTEM CLEAN; SKIPPING CHECKS /dev/ad0s2a: clean, 37241 free (1089 frags, 4519 blocks, 0.6% fragmentation) g_post_event_x(0xc04cb510, 0xc3ae4400, 2, 0) ref 0xc3ae4400 g_label_taste(LABEL, ad0s2a) g_slice_config(ad0s2a, 0, 1) g_post_event_x(0xc04cb510, 0xc3b26080, 2, 0) ref 0xc3b26080 ref 0xc3b26000 GEOM_LABEL: Label for provider ad0s2a is ufsid/46387cd616292ca8. g_detach(0xc3af69c0) g_destroy_consumer(0xc3af69c0) g_destroy_geom(0xc3b6d680(label:taste)) g_part_taste(PART,ad0s2a) g_wither_geom(0xc3b25e00(ad0s2a)) g_label_taste(LABEL, ufsid/46387cd616292ca8) dev_taste(DEV,ufsid/46387cd616292ca8) g_part_taste(PART,ufsid/46387cd616292ca8) g_wither_geom(0xc3b26400(ufsid/46387cd616292ca8)) g_detach(0xc3af68c0) g_destroy_consumer(0xc3af68c0) g_destroy_geom(0xc3b26400(ufsid/46387cd616292ca8)) g_detach(0xc3af6940) g_destroy_consumer(0xc3af6940) g_destroy_geom(0xc3b25e00(ad0s2a)) g_post_event_x(0xc04cb710, 0xc3ae4200, 2, 0) ref 0xc3ae4200 GEOM_LABEL: Label ufsid/46387cd73d66d2ca removed. g_slice_spoiled(0xc3add300/ad0s2d) g_wither_geom(0xc3ae4280(ad0s2d)) g_orphan_provider(0xc3ae4600(ufsid/46387cd73d66d2ca), 6) g_orphan_register(ufsid/46387cd73d66d2ca) g_dev_orphan(0xc3af6080(ufsid/46387cd73d66d2ca)) g_detach(0xc3af6080) g_destroy_consumer(0xc3af6080) g_destroy_geom(0xc3ae4980(ufsid/46387cd73d66d2ca)) g_detach(0xc3add300) g_destroy_consumer(0xc3add300) g_destroy_geom(0xc3ae4280(ad0s2d)) /dev/ad0s2d: FILE SYSTEM CLEAN; SKIPPING CHECKS /dev/ad0s2d: clean, 65381 free (5149 frags, 7529 blocks, 5.4% fragmentation) g_post_event_x(0xc04cb510, 0xc3ae4200, 2, 0) ref 0xc3ae4200 g_label_taste(LABEL, ad0s2d) g_slice_config(ad0s2d, 0, 1) g_post_event_x(0xc04cb510, 0xc3b25e00, 2, 0) ref 0xc3b25e00 ref 0xc3b26900 GEOM_LABEL: Label for provider ad0s2d is ufsid/46387cd73d66d2ca. g_detach(0xc3af66c0) g_destroy_consumer(0xc3af66c0) g_destroy_geom(0xc3b26200(label:taste)) g_part_taste(PART,ad0s2d) g_wither_geom(0xc3b25d80(ad0s2d)) g_label_taste(LABEL, ufsid/46387cd73d66d2ca) dev_taste(DEV,ufsid/46387cd73d66d2ca) g_part_taste(PART,ufsid/46387cd73d66d2ca) g_wither_geom(0xc3b6d480(ufsid/46387cd73d66d2ca)) g_detach(0xc3af65c0) g_destroy_consumer(0xc3af65c0) g_destroy_geom(0xc3b6d480(ufsid/46387cd73d66d2ca)) g_detach(0xc3af6640) g_destroy_consumer(0xc3af6640) g_destroy_geom(0xc3b25d80(ad0s2d)) g_post_event_x(0xc04cb710, 0xc3ae4100, 2, 0) ref 0xc3ae4100 GEOM_LABEL: Label ufsid/46387cd6c10fa381 removed. g_slice_spoiled(0xc3add1c0/ad0s2e) g_wither_geom(0xc3af3900(ad0s2e)) g_orphan_provider(0xc3af3880(ufsid/46387cd6c10fa381), 6) g_orphan_register(ufsid/46387cd6c10fa381) g_dev_orphan(0xc3af6000(ufsid/46387cd6c10fa381)) g_detach(0xc3af6000) g_destroy_consumer(0xc3af6000) g_destroy_geom(0xc3ae4380(ufsid/46387cd6c10fa381)) g_detach(0xc3add1c0) g_destroy_consumer(0xc3add1c0) g_destroy_geom(0xc3af3900(ad0s2e)) /dev/ad0s2e: FILE SYSTEM CLEAN; SKIPPING CHECKS /dev/ad0s2e: clean, 689500 free (141532 frags, 68496 blocks, 5.1% fragmentation) g_post_event_x(0xc04cb510, 0xc3ae4100, 2, 0) ref 0xc3ae4100 g_label_taste(LABEL, ad0s2e) g_slice_config(ad0s2e, 0, 1) g_post_event_x(0xc04cb510, 0xc3af3880, 2, 0) ref 0xc3af3880 ref 0xc3af3900 GEOM_LABEL: Label for provider ad0s2e is ufsid/46387cd6c10fa381. g_detach(0xc3af6480) g_destroy_consumer(0xc3af6480) g_destroy_geom(0xc3ae4b00(label:taste)) g_part_taste(PART,ad0s2e) g_wither_geom(0xc3ae0780(ad0s2e)) g_label_taste(LABEL, ufsid/46387cd6c10fa381) dev_taste(DEV,ufsid/46387cd6c10fa381) g_part_taste(PART,ufsid/46387cd6c10fa381) g_wither_geom(0xc3b6d480(ufsid/46387cd6c10fa381)) g_detach(0xc3af6380) g_destroy_consumer(0xc3af6380) g_destroy_geom(0xc3b6d480(ufsid/46387cd6c10fa381)) g_detach(0xc3af6400) g_destroy_consumer(0xc3af6400) g_destroy_geom(0xc3ae0780(ad0s2e)) g_post_event_x(0xc04cb710, 0xc39a8d80, 2, 0) ref 0xc39a8d80 g_post_event_x(0xc04cb710, 0xc3ae0b00, 2, 0) ref 0xc3ae0b00 g_part_spoiled(ad0s3+00103bf1) g_wither_geom(0xc3af3000(ad0s3+00103bf1)) g_orphan_provider(0xc3ae4e00(ad0s3+00103bf1a), 6) g_orphan_register(ad0s3+00103bf1a) g_dev_orphan(0xc3ae2cc0(ad0s3+00103bf1a)) g_detach(0xc3ae2cc0) g_destroy_consumer(0xc3ae2cc0) g_destroy_geom(0xc3ae0c80(ad0s3+00103bf1a)) GEOM_LABEL: Label ufsid/46389322544a8c64 removed. g_slice_orphan(0xc3ae2d00/ad0s3+00103bf1a) g_wither_geom(0xc3ae0b80(ad0s3+00103bf1a)) g_orphan_provider(0xc3af3180(ufsid/46389322544a8c64), 6) g_orphan_register(ufsid/46389322544a8c64) g_dev_orphan(0xc3ae2c00(ufsid/46389322544a8c64)) g_detach(0xc3ae2c00) g_destroy_consumer(0xc3ae2c00) g_destroy_geom(0xc3af3680(ufsid/46389322544a8c64)) g_detach(0xc3ae2d00) g_destroy_consumer(0xc3ae2d00) g_destroy_geom(0xc3ae0b80(ad0s3+00103bf1a)) g_detach(0xc3addb40) g_destroy_consumer(0xc3addb40) g_destroy_geom(0xc3af3000(ad0s3+00103bf1)) /dev/ad0s7: FILE SYSTEM CLEAN; SKIPPING CHECKS /dev/ad0s7: clean, 4999758 free (51910 frags, 618481 blocks, 0.7% fragmentation) g_post_event_x(0xc04cb510, 0xc39a8d80, 2, 0) ref 0xc39a8d80 g_post_event_x(0xc04cb510, 0xc3ae0b00, 2, 0) ref 0xc3ae0b00 g_label_taste(LABEL, ad0s3) g_detach(0xc3ae2c00) g_destroy_consumer(0xc3ae2c00) g_destroy_geom(0xc3ae0b80(label:taste)) g_label_taste(LABEL, ad0s3+00103bf1) g_detach(0xc3ae2cc0) g_destroy_consumer(0xc3ae2cc0) g_destroy_geom(0xc3af3180(label:taste)) g_part_taste(PART,ad0s3+00103bf1) g_post_event_x(0xc04cb510, 0xc3b26200, 2, 0) ref 0xc3b26200 ref 0xc3af3680 g_label_taste(LABEL, ad0s3+00103bf1a) g_slice_config(ad0s3+00103bf1a, 0, 1) g_post_event_x(0xc04cb510, 0xc3ae0780, 2, 0) ref 0xc3ae0780 ref 0xc3b26800 GEOM_LABEL: Label for provider ad0s3+00103bf1a is ufsid/46389322544a8c64. g_detach(0xc3af6380) g_destroy_consumer(0xc3af6380) g_destroy_geom(0xc3ae4980(label:taste)) dev_taste(DEV,ad0s3+00103bf1a) g_part_taste(PART,ad0s3+00103bf1a) g_wither_geom(0xc3b6d580(ad0s3+00103bf1a)) g_label_taste(LABEL, ufsid/46389322544a8c64) dev_taste(DEV,ufsid/46389322544a8c64) g_part_taste(PART,ufsid/46389322544a8c64) g_wither_geom(0xc3ae4980(ufsid/46389322544a8c64)) g_detach(0xc3af6000) g_destroy_consumer(0xc3af6000) g_destroy_geom(0xc3ae4980(ufsid/46389322544a8c64)) g_detach(0xc3af6540) g_destroy_consumer(0xc3af6540) g_destroy_geom(0xc3b6d580(ad0s3+00103bf1a)) g_post_event_x(0xc04cb710, 0xc3ae4400, 2, 0) ref 0xc3ae4400 GEOM_LABEL: Label ufsid/46387cd616292ca8 removed. g_slice_spoiled(0xc3af6980/ad0s2a) g_wither_geom(0xc3b26000(ad0s2a)) g_orphan_provider(0xc3b26080(ufsid/46387cd616292ca8), 6) g_orphan_register(ufsid/46387cd616292ca8) g_dev_orphan(0xc3af6900(ufsid/46387cd616292ca8)) g_detach(0xc3af6900) g_destroy_consumer(0xc3af6900) g_destroy_geom(0xc3b25c80(ufsid/46387cd616292ca8)) g_detach(0xc3af6980) g_destroy_consumer(0xc3af6980) g_destroy_geom(0xc3b26000(ad0s2a)) g_post_event_x(0xc04cb710, 0xc3ae4200, 2, 0) ref 0xc3ae4200 GEOM_LABEL: Label ufsid/46387cd73d66d2ca removed. g_slice_spoiled(0xc3af6680/ad0s2d) g_wither_geom(0xc3b26900(ad0s2d)) g_orphan_provider(0xc3b25e00(ufsid/46387cd73d66d2ca), 6) g_orphan_register(ufsid/46387cd73d66d2ca) g_dev_orphan(0xc3af6600(ufsid/46387cd73d66d2ca)) g_detach(0xc3af6600) g_destroy_consumer(0xc3af6600) g_destroy_geom(0xc3b6d600(ufsid/46387cd73d66d2ca)) g_detach(0xc3af6680) g_destroy_consumer(0xc3af6680) g_destroy_geom(0xc3b26900(ad0s2d)) g_post_event_x(0xc04cb710, 0xc3ae4100, 2, 0) ref 0xc3ae4100 GEOM_LABEL: Label ufsid/46387cd6c10fa381 removed. g_slice_spoiled(0xc3af6440/ad0s2e) g_wither_geom(0xc3af3900(ad0s2e)) g_orphan_provider(0xc3af3880(ufsid/46387cd6c10fa381), 6) g_orphan_register(ufsid/46387cd6c10fa381) g_dev_orphan(0xc3af63c0(ufsid/46387cd6c10fa381)) g_detach(0xc3af63c0) g_destroy_consumer(0xc3af63c0) g_destroy_geom(0xc3b26880(ufsid/46387cd6c10fa381)) g_detach(0xc3af6440) g_destroy_consumer(0xc3af6440) g_destroy_geom(0xc3af3900(ad0s2e)) g_post_event_x(0xc04cb710, 0xc39a8d80, 2, 0) ref 0xc39a8d80 g_post_event_x(0xc04cb710, 0xc3ae0b00, 2, 0) ref 0xc3ae0b00 g_part_spoiled(ad0s3+00103bf1) g_wither_geom(0xc3af3680(ad0s3+00103bf1)) g_orphan_provider(0xc3b26200(ad0s3+00103bf1a), 6) g_orphan_register(ad0s3+00103bf1a) g_dev_orphan(0xc3af64c0(ad0s3+00103bf1a)) g_detach(0xc3af64c0) g_destroy_consumer(0xc3af64c0) g_destroy_geom(0xc3ae4380(ad0s3+00103bf1a)) GEOM_LABEL: Label ufsid/46389322544a8c64 removed. g_slice_orphan(0xc3af6480/ad0s3+00103bf1a) g_wither_geom(0xc3b26800(ad0s3+00103bf1a)) g_orphan_provider(0xc3ae0780(ufsid/46389322544a8c64), 6) g_orphan_register(ufsid/46389322544a8c64) g_dev_orphan(0xc3add1c0(ufsid/46389322544a8c64)) g_detach(0xc3add1c0) g_destroy_consumer(0xc3add1c0) g_destroy_geom(0xc3ae4b00(ufsid/46389322544a8c64)) g_detach(0xc3af6480) g_destroy_consumer(0xc3af6480) g_destroy_geom(0xc3b26800(ad0s3+00103bf1a)) g_detach(0xc3add340) g_destroy_consumer(0xc3add340) g_destroy_geom(0xc3af3680(ad0s3+00103bf1)) g_modevent(MD, LOAD) g_post_event_x(0xc04cd490, 0xc3ae19f0, 2, 262144) g_load_class(MD) g_post_event_x(0xc04cb510, 0xc3b25e00, 2, 0) ref 0xc3b25e00 ref 0xc3b26900 g_label_taste(LABEL, md0) g_slice_config(md0, 0, 1) g_post_event_x(0xc04cb510, 0xc3b26d80, 2, 0) ref 0xc3b26d80 ref 0xc3ae4280 GEOM_LABEL: Label for provider md0 is ufsid/49d71e25191c321d. g_detach(0xc3af6c40) g_destroy_consumer(0xc3af6c40) g_destroy_geom(0xc3b26080(label:taste)) dev_taste(DEV,md0) g_part_taste(PART,md0) g_wither_geom(0xc3b26700(md0)) g_label_taste(LABEL, ufsid/49d71e25191c321d) dev_taste(DEV,ufsid/49d71e25191c321d) g_part_taste(PART,ufsid/49d71e25191c321d) g_wither_geom(0xc3b26200(ufsid/49d71e25191c321d)) g_detach(0xc3af6dc0) g_destroy_consumer(0xc3af6dc0) g_destroy_geom(0xc3b26200(ufsid/49d71e25191c321d)) g_detach(0xc3af6d00) g_destroy_consumer(0xc3af6d00) g_destroy_geom(0xc3b26700(md0)) g_post_event_x(0xc04cb710, 0xc3b25e00, 2, 0) ref 0xc3b25e00 GEOM_LABEL: Label ufsid/49d71e25191c321d removed. g_slice_spoiled(0xc3af6c80/md0) g_wither_geom(0xc3ae4280(md0)) g_orphan_provider(0xc3b26d80(ufsid/49d71e25191c321d), 6) g_orphan_register(ufsid/49d71e25191c321d) g_dev_orphan(0xc3af6d80(ufsid/49d71e25191c321d)) g_detach(0xc3af6d80) g_destroy_consumer(0xc3af6d80) g_destroy_geom(0xc3ae4980(ufsid/49d71e25191c321d)) g_detach(0xc3af6c80) g_destroy_consumer(0xc3af6c80) g_destroy_geom(0xc3ae4280(md0)) g_post_event_x(0xc04cb510, 0xc3b25e00, 2, 0) ref 0xc3b25e00 g_label_taste(LABEL, md0) g_slice_config(md0, 0, 1) g_post_event_x(0xc04cb510, 0xc3b26d80, 2, 0) ref 0xc3b26d80 ref 0xc3ae4280 GEOM_LABEL: Label for provider md0 is ufsid/49d73f4d44e77d1b. g_detach(0xc3b6f100) g_destroy_consumer(0xc3b6f100) g_destroy_geom(0xc3ae4b00(label:taste)) g_part_taste(PART,md0) g_wither_geom(0xc3ae4380(md0)) g_label_taste(LABEL, ufsid/49d73f4d44e77d1b) dev_taste(DEV,ufsid/49d73f4d44e77d1b) g_part_taste(PART,ufsid/49d73f4d44e77d1b) g_wither_geom(0xc3b26800(ufsid/49d73f4d44e77d1b)) g_detach(0xc3b6f1c0) g_destroy_consumer(0xc3b6f1c0) g_destroy_geom(0xc3b26800(ufsid/49d73f4d44e77d1b)) g_detach(0xc3b6f180) g_destroy_consumer(0xc3b6f180) g_destroy_geom(0xc3ae4380(md0)) g_post_event_x(0xc04cb710, 0xc3b25e00, 2, 0) ref 0xc3b25e00 GEOM_LABEL: Label ufsid/49d73f4d44e77d1b removed. g_slice_spoiled(0xc3b6f0c0/md0) g_wither_geom(0xc3ae4280(md0)) g_orphan_provider(0xc3b26d80(ufsid/49d73f4d44e77d1b), 6) g_orphan_register(ufsid/49d73f4d44e77d1b) g_dev_orphan(0xc3b6f200(ufsid/49d73f4d44e77d1b)) g_detach(0xc3b6f200) g_destroy_consumer(0xc3b6f200) g_destroy_geom(0xc3b26200(ufsid/49d73f4d44e77d1b)) g_detach(0xc3b6f0c0) g_destroy_consumer(0xc3b6f0c0) g_destroy_geom(0xc3ae4280(md0)) procfs registered linprocfs registered -- Thanks, Tai-hwa Liang From alex.wilkinson at dsto.defence.gov.au Fri Apr 3 22:37:11 2009 From: alex.wilkinson at dsto.defence.gov.au (Wilkinson, Alex) Date: Fri Apr 3 22:37:18 2009 Subject: Removal of GEOM_BSD, GEOM_MBR, GEOM_PC98 and GEOM_SUNLABEL In-Reply-To: References: <20090331155542.74d89d64@ernst.jennejohn.org> <60084D1E-9F64-463A-A8E9-7A237D5C7661@mac.com> <0904011910169.29800@www.mmlab.cse.yzu.edu.tw> <0904020940371.36257@www.mmlab.cse.yzu.edu.tw> <4CCDEFD6-830E-4C8F-B7A2-B7878F8842BE@mac.com> <0904021314574.37737@www.mmlab.cse.yzu.edu.tw> <09040309313414.76643@www.mmlab.cse.yzu.edu.tw> Message-ID: <20090404053655.GH3597@stlux503.dsto.defence.gov.au> 0n Thu, Apr 02, 2009 at 09:44:02PM -0700, Marcel Moolenaar wrote: >*snip* >> 000001b0 00 00 00 00 00 f2 0e 00 00 00 00 00 00 00 00 01 >> |................| >> 000001c0 c1 ff 83 ef ff ff 3f 00 00 00 21 17 00 01 00 00 >> |......?...!.....| >> 000001d0 c1 ff 05 ef ff ff 60 17 00 01 b0 a8 fe 02 00 00 >> |......`.........| >> 000001e0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >> |................| >> 000001f0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 55 aa >> |..............U.| >*snip* > >It looks like you have a boot menu entry at 0x1b6. Can you >try the following patch: OK, excuse my lack of skill here, but Marcel how in the hell did you decifer that ? -aW IMPORTANT: This email remains the property of the Australian Defence Organisation and is subject to the jurisdiction of section 70 of the CRIMES ACT 1914. If you have received this email in error, you are requested to contact the sender and delete the email. From xcllnt at mac.com Fri Apr 3 22:55:54 2009 From: xcllnt at mac.com (Marcel Moolenaar) Date: Fri Apr 3 22:56:02 2009 Subject: Removal of GEOM_BSD, GEOM_MBR, GEOM_PC98 and GEOM_SUNLABEL In-Reply-To: <09040411131618.87313@www.mmlab.cse.yzu.edu.tw> References: <95891.1238477069@critter.freebsd.dk> <20090331133132.1e191836@ernst.jennejohn.org> <20090331155542.74d89d64@ernst.jennejohn.org> <60084D1E-9F64-463A-A8E9-7A237D5C7661@mac.com> <0904011910169.29800@www.mmlab.cse.yzu.edu.tw> <0904020940371.36257@www.mmlab.cse.yzu.edu.tw> <4CCDEFD6-830E-4C8F-B7A2-B7878F8842BE@mac.com> <0904021314574.37737@www.mmlab.cse.yzu.edu.tw> <09040309313414.76643@www.mmlab.cse.yzu.edu.tw> <0904031327195.78401@www.mmlab.cse.yzu.edu.tw> <8583A3BA-2871-4DF4-9792-1031044A4A22@mac.com> <09040315161311.79260@www.mmlab.cse.yzu.edu.tw> <1DDB4728-7742-4265-999F-F1A0FC69F9E4@mac.com> <0904040858433.86299@www.mmlab.cse.yzu.edu.tw> <7AD352A2-BEDD-4DFD-896D-104E6376D887@mac.com> <09040411131618.87313@www.mmlab.cse.yzu.edu.tw> Message-ID: On Apr 3, 2009, at 8:15 PM, Tai-hwa Liang wrote: > g_part_taste(PART,ad0) > g_part_taste(PART,ad0s1) > g_part_taste(PART,ad0s2) > g_part_taste(PART,ad0s3) > g_part_taste(PART,msdosfs/IBM_PRELOAD) > g_part_taste(PART,ad0s2a) > g_part_taste(PART,ad0s2b) > g_part_taste(PART,ad0s2d) > g_part_taste(PART,ad0s2e) > g_part_taste(PART,ad0s3+00000001) > g_part_taste(PART,ad0s3+000410a1) > g_part_taste(PART,ad0s3+00103bf1) > g_part_taste(PART,ad0s3+0017cda1) > g_part_taste(PART,ufsid/46387cd616292ca8) > g_part_taste(PART,ufsid/46387cd73d66d2ca) > g_part_taste(PART,ufsid/46387cd6c10fa381) > g_part_taste(PART,msdosfs/ ) > g_part_taste(PART,ad0s3+00103bf1a) > g_part_taste(PART,ufsid/46389322544a8c64) > g_part_taste(PART,acd0) > g_part_taste(PART,cd0) > g_part_taste(PART,ad0s2a) > g_part_taste(PART,ufsid/46387cd616292ca8) > g_part_taste(PART,ad0s2d) > g_part_taste(PART,ufsid/46387cd73d66d2ca) > g_part_taste(PART,ad0s2e) > g_part_taste(PART,ufsid/46387cd6c10fa381) > g_part_spoiled(ad0s3+00103bf1) > /dev/ad0s7: FILE SYSTEM CLEAN; SKIPPING CHECKS > /dev/ad0s7: clean, 4999758 free (51910 frags, 618481 blocks, 0.7% > fragmentation) > g_part_taste(PART,ad0s3+00103bf1) > g_part_taste(PART,ad0s3+00103bf1a) > g_part_taste(PART,ufsid/46389322544a8c64) > g_part_spoiled(ad0s3+00103bf1) > g_part_taste(PART,md0) > g_part_taste(PART,ufsid/49d71e25191c321d) > g_part_taste(PART,md0) > g_part_taste(PART,ufsid/49d73f4d44e77d1b) I think your /etc/fstab is wrong. fsck is run on /dev/ad0s7 and not on /dev/ad0s7a. That's why the geom is spoiled and gpart show doesn't list the partition. FYI, -- Marcel Moolenaar xcllnt@mac.com From thierry.herbelot at free.fr Sat Apr 4 01:50:45 2009 From: thierry.herbelot at free.fr (Thierry Herbelot) Date: Sat Apr 4 01:50:53 2009 Subject: Stuck kernel while cleaning up the object tree Message-ID: <200904041050.28932.thierry.herbelot@free.fr> Hello, On recent -current machines, I have seen a common pattern, with the machine being frozen (still responsive to pings, though) in the initial phases of the buildworld procedure : example freeze : -------------------------------------------------------------- >>> stage 2.1: cleaning up the object tree -------------------------------------------------------------- cd /usr/src; MAKEOBJDIRPREFIX=/usr/obj MACHINE_ARCH=i386 MACHINE=i386 CPUTYPE= GROFF_BIN_PATH=/usr/obj/usr/src/tmp/legacy/usr/bin GROFF_FONT_PATH=/usr/obj/usr/src/tmp/legacy/usr/share/groff_font GROFF_TMAC_PATH=/usr/obj/usr/src/tmp/legacy/usr/share/tmac _SHLIBDIRPREFIX=/usr/obj/usr/src/tmp VERSION="FreeBSD 8.0-CURRENT i386 800074" INSTALL="sh /usr/src/tools/install.sh" PATH=/usr/obj/usr/src/tmp/legacy/usr/sbin:/usr/obj/usr/src/tmp/legacy/usr/bin:/usr/obj/usr/src/tmp/legacy/usr/games:/usr/obj/usr/src/tmp/usr/sbin:/usr/obj/usr/src/tmp/usr/bin:/usr/obj/usr/src/tmp/usr/games:/sbin:/bin:/usr/sbin:/usr/bin NO_CTF=1 make -f Makefile.inc1 DESTDIR=/usr/obj/usr/src/tmp par-cleandir ===> share/info (cleandir) ===> lib (cleandir) ===> lib/csu/i386-elf (cleandir) [type ^T in the console] load: 0.00 cmd: sh 24587 [*Name Cache] 0.01u 0.00s 0% 1584k The other machines also froze while "cleaning up the object tree". The machines are configured with serial consoles : I have no kernel stack backtrace to aid in pinpointing the cause of this freeze. Cheers TfH From thierry.herbelot at free.fr Sat Apr 4 02:51:34 2009 From: thierry.herbelot at free.fr (Thierry Herbelot) Date: Sat Apr 4 02:51:42 2009 Subject: Stuck kernel while cleaning up the object tree In-Reply-To: <200904041050.28932.thierry.herbelot@free.fr> References: <200904041050.28932.thierry.herbelot@free.fr> Message-ID: <200904041151.18209.thierry.herbelot@free.fr> Le Saturday 04 April 2009, Thierry Herbelot a ?crit : > Hello, > > On recent -current machines, I have seen a common pattern, with the machine > being frozen (still responsive to pings, though) in the initial phases of > the buildworld procedure : > > example freeze : > -------------------------------------------------------------- > > >>> stage 2.1: cleaning up the object tree > > -------------------------------------------------------------- > cd /usr/src; MAKEOBJDIRPREFIX=/usr/obj MACHINE_ARCH=i386 MACHINE=i386 > CPUTYPE= GROFF_BIN_PATH=/usr/obj/usr/src/tmp/legacy/usr/bin > GROFF_FONT_PATH=/usr/obj/usr/src/tmp/legacy/usr/share/groff_font > GROFF_TMAC_PATH=/usr/obj/usr/src/tmp/legacy/usr/share/tmac > _SHLIBDIRPREFIX=/usr/obj/usr/src/tmp VERSION="FreeBSD 8.0-CURRENT i386 > 800074" INSTALL="sh /usr/src/tools/install.sh" > PATH=/usr/obj/usr/src/tmp/legacy/usr/sbin:/usr/obj/usr/src/tmp/legacy/usr/b >in:/usr/obj/usr/src/tmp/legacy/usr/games:/usr/obj/usr/src/tmp/usr/sbin:/usr/ >obj/usr/src/tmp/usr/bin:/usr/obj/usr/src/tmp/usr/games:/sbin:/bin:/usr/sbin: >/usr/bin NO_CTF=1 make -f Makefile.inc1 DESTDIR=/usr/obj/usr/src/tmp > par-cleandir ===> share/info (cleandir) > ===> lib (cleandir) > ===> lib/csu/i386-elf (cleandir) > [type ^T in the console] > load: 0.00 cmd: sh 24587 [*Name Cache] 0.01u 0.00s 0% 1584k > > The other machines also froze while "cleaning up the object tree". > > The machines are configured with serial consoles : I have no kernel stack > backtrace to aid in pinpointing the cause of this freeze. > > Cheers > > TfH With a bit more investigation : on a separate ssh session, top is still live and shows processes stuck as : 24523 root 1 76 0 1888K 764K *Name 1 0:00 0.00% make on still another machine, running Witnesses (all other machines run with a lean GENERIC, with most of the debuging features commented out) : System call __getcwd returning with the following locks held: shared rw Name Cache (Name Cache) r = 0 (0xc0ee7e1c) locked @ /usr/src/sys/kerne/vfs_cache.c:974 panic: witness_warn cpuid = 0 KDB: enter: panic TfH > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" From bsam at ipt.ru Sat Apr 4 03:11:59 2009 From: bsam at ipt.ru (Boris Samorodov) Date: Sat Apr 4 03:12:07 2009 Subject: Stuck kernel while cleaning up the object tree In-Reply-To: <200904041151.18209.thierry.herbelot@free.fr> (Thierry Herbelot's message of "Sat\, 4 Apr 2009 11\:51\:17 +0200") References: <200904041050.28932.thierry.herbelot@free.fr> <200904041151.18209.thierry.herbelot@free.fr> Message-ID: <10969763@bb.ipt.ru> On Sat, 4 Apr 2009 11:51:17 +0200 Thierry Herbelot wrote: > Le Saturday 04 April 2009, Thierry Herbelot a ?crit : > > Hello, > > > > On recent -current machines, I have seen a common pattern, with the machine > > being frozen (still responsive to pings, though) in the initial phases of > > the buildworld procedure : > > > > example freeze : > > -------------------------------------------------------------- > > > > >>> stage 2.1: cleaning up the object tree > > > > -------------------------------------------------------------- > > cd /usr/src; MAKEOBJDIRPREFIX=/usr/obj MACHINE_ARCH=i386 MACHINE=i386 > > CPUTYPE= GROFF_BIN_PATH=/usr/obj/usr/src/tmp/legacy/usr/bin > > GROFF_FONT_PATH=/usr/obj/usr/src/tmp/legacy/usr/share/groff_font > > GROFF_TMAC_PATH=/usr/obj/usr/src/tmp/legacy/usr/share/tmac > > _SHLIBDIRPREFIX=/usr/obj/usr/src/tmp VERSION="FreeBSD 8.0-CURRENT i386 > > 800074" INSTALL="sh /usr/src/tools/install.sh" > > PATH=/usr/obj/usr/src/tmp/legacy/usr/sbin:/usr/obj/usr/src/tmp/legacy/usr/b > >in:/usr/obj/usr/src/tmp/legacy/usr/games:/usr/obj/usr/src/tmp/usr/sbin:/usr/ > >obj/usr/src/tmp/usr/bin:/usr/obj/usr/src/tmp/usr/games:/sbin:/bin:/usr/sbin: > >/usr/bin NO_CTF=1 make -f Makefile.inc1 DESTDIR=/usr/obj/usr/src/tmp > > par-cleandir ===> share/info (cleandir) > > ===> lib (cleandir) > > ===> lib/csu/i386-elf (cleandir) > > [type ^T in the console] > > load: 0.00 cmd: sh 24587 [*Name Cache] 0.01u 0.00s 0% 1584k > > > > The other machines also froze while "cleaning up the object tree". > > > > The machines are configured with serial consoles : I have no kernel stack > > backtrace to aid in pinpointing the cause of this freeze. > > > > Cheers > > > > TfH > With a bit more investigation : > on a separate ssh session, top is still live and shows processes stuck as : > 24523 root 1 76 0 1888K 764K *Name 1 0:00 0.00% make > on still another machine, running Witnesses (all other machines run with a > lean GENERIC, with most of the debuging features commented out) : > System call __getcwd returning with the following locks held: > shared rw Name Cache (Name Cache) r = 0 (0xc0ee7e1c) locked > @ /usr/src/sys/kerne/vfs_cache.c:974 This is definitely related to: SVN rev 190655 on 2009-04-02 21:16:20Z by peter (peter@ CCed) > panic: witness_warn > cpuid = 0 > KDB: enter: panic WBR -- Boris Samorodov (bsam) Research Engineer, http://www.ipt.ru Telephone & Internet SP FreeBSD Committer, http://www.FreeBSD.org The Power To Serve From M.S.Powell at salford.ac.uk Sat Apr 4 04:55:50 2009 From: M.S.Powell at salford.ac.uk (Mark Powell) Date: Sat Apr 4 04:55:57 2009 Subject: panic: vput: negative ref cnt Message-ID: <20090404124909.C24261@rust.salford.ac.uk> Hi, Getting a reproducable panic during backups: panic: vput: negative ref cnt cpuid = 0 KDB: enter: panic [thread pid 3521 tid 100374 ] Stopped at kdb_enter+0x3d: movq $0,0x654104(%rip) db> bt Tracing pid 3521 tid 100374 0xffffff008c79e380 kdb_enter() at kdb_enter+0x3d panic() at panic+0x176 vput() at vput+0x10c dounmount() at dounmount0x421 unmount() at unmount+0x24b syscall() at syscall+0x1bf Xfast_syscall() at Xfast_syscall+0xab --- syscall (22, FreeBSD ELF64, unmount), rip = 0x800695d7c, rsp = 0x7fffffffe218, rbp = 0 --- My script takes a zfs snapshot, mounts the snapshot, backs it up using star, then umounts the snapshot. The panic seems to occur on the umount. Cheers. -- Mark Powell - UNIX System Administrator - The University of Salford Information & Learning Services, Clifford Whitworth Building, Salford University, Manchester, M5 4WT, UK. Tel: +44 161 295 6843 Fax: +44 161 295 5888 www.pgp.com for PGP key From michael.copeland at gmail.com Sat Apr 4 05:30:14 2009 From: michael.copeland at gmail.com (michael) Date: Sat Apr 4 05:30:21 2009 Subject: rt2870 wireless chipset Message-ID: <49D752D2.4090902@gmail.com> is this chip or will this chip be covered under the rum module? if it has not already been started on, i've noticed from looking at the ralink opensource driver that it seems be structured nearly identical to the rt73 driver. eg: its used in the version 3 of the linksys WUSB54GC compact wireless adapter. version 1 was the rt73 which already works with the rum module. what i'm asking is, since the two linux drivers seem nearly identical; would it be very difficult for me to copy the rum driver source to another directory and make the changes evident in the linux driver(mainly dealing with loading the rt2870 firmware file) in the copied rum driver? thank you for your insight, michael From christoph.mallon at gmx.de Sat Apr 4 05:54:42 2009 From: christoph.mallon at gmx.de (Christoph Mallon) Date: Sat Apr 4 05:54:49 2009 Subject: Removal of GEOM_BSD, GEOM_MBR, GEOM_PC98 and GEOM_SUNLABEL In-Reply-To: <20090404053655.GH3597@stlux503.dsto.defence.gov.au> References: <20090331155542.74d89d64@ernst.jennejohn.org> <60084D1E-9F64-463A-A8E9-7A237D5C7661@mac.com> <0904011910169.29800@www.mmlab.cse.yzu.edu.tw> <0904020940371.36257@www.mmlab.cse.yzu.edu.tw> <4CCDEFD6-830E-4C8F-B7A2-B7878F8842BE@mac.com> <0904021314574.37737@www.mmlab.cse.yzu.edu.tw> <09040309313414.76643@www.mmlab.cse.yzu.edu.tw> <20090404053655.GH3597@stlux503.dsto.defence.gov.au> Message-ID: <49D7524D.1090508@gmx.de> Wilkinson, Alex schrieb: > 0n Thu, Apr 02, 2009 at 09:44:02PM -0700, Marcel Moolenaar wrote: > > >*snip* > >> 000001b0 00 00 00 00 00 f2 0e 00 00 00 00 00 00 00 00 01 > >> |................| > >> 000001c0 c1 ff 83 ef ff ff 3f 00 00 00 21 17 00 01 00 00 > >> |......?...!.....| > >> 000001d0 c1 ff 05 ef ff ff 60 17 00 01 b0 a8 fe 02 00 00 > >> |......`.........| > >> 000001e0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > >> |................| > >> 000001f0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 55 aa > >> |..............U.| > >*snip* > > > >It looks like you have a boot menu entry at 0x1b6. Can you > >try the following patch: > > OK, excuse my lack of skill here, but Marcel how in the hell did you decifer that ? Read from the back: The last two bytes (55 AA) are a magic marker. Before that are four times 16 bytes, which describe the four possible partitions (start, size, type etc.). For MBRs (Master Boot Record) all four can be used, for EBRs (Extended Boot Record) the 3rd and 4th are always zero (i.e. unused). Before that (0x01B5 till 0x01BD) are are the nine non-zero bytes, which caused the trouble. More info about the layout of the partition entries etc.: http://en.wikipedia.org/wiki/Extended_Boot_Record Christoph From onemda at gmail.com Sat Apr 4 06:38:23 2009 From: onemda at gmail.com (Paul B. Mahol) Date: Sat Apr 4 06:38:29 2009 Subject: rt2870 wireless chipset In-Reply-To: <49D752D2.4090902@gmail.com> References: <49D752D2.4090902@gmail.com> Message-ID: <3a142e750904040638p5714282cwab08835d00ea4dde@mail.gmail.com> On 4/4/09, michael wrote: > is this chip or will this chip be covered under the rum module? if it > has not already been started on, i've noticed from looking at the ralink > opensource driver that it seems be structured nearly identical to the > rt73 driver. eg: its used in the version 3 of the linksys WUSB54GC > compact wireless adapter. version 1 was the rt73 which already works > with the rum module. what i'm asking is, since the two linux drivers > seem nearly identical; would it be very difficult for me to copy the rum > driver source to another directory and make the changes evident in the > linux driver(mainly dealing with loading the rt2870 firmware file) in > the copied rum driver? What about non evident things :-), Just go ahead, but note that if you make some terrible mistake that you can say goodbye to chip. -- Paul From avatar at mmlab.cse.yzu.edu.tw Sat Apr 4 08:16:52 2009 From: avatar at mmlab.cse.yzu.edu.tw (Tai-hwa Liang) Date: Sat Apr 4 08:16:59 2009 Subject: Removal of GEOM_BSD, GEOM_MBR, GEOM_PC98 and GEOM_SUNLABEL In-Reply-To: References: <20090331155542.74d89d64@ernst.jennejohn.org> <60084D1E-9F64-463A-A8E9-7A237D5C7661@mac.com> <0904011910169.29800@www.mmlab.cse.yzu.edu.tw> <0904020940371.36257@www.mmlab.cse.yzu.edu.tw> <4CCDEFD6-830E-4C8F-B7A2-B7878F8842BE@mac.com> <0904021314574.37737@www.mmlab.cse.yzu.edu.tw> <09040309313414.76643@www.mmlab.cse.yzu.edu.tw> <0904031327195.78401@www.mmlab.cse.yzu.edu.tw> <8583A3BA-2871-4DF4-9792-1031044A4A22@mac.com> <09040315161311.79260@www.mmlab.cse.yzu.edu.tw> <1DDB4728-7742-4265-999F-F1A0FC69F9E4@mac.com> <0904040858433.86299@www.mmlab.cse.yzu.edu.tw> <7AD352A2-BEDD-4DFD-896D-104E6376D887@mac.com> <09040411131618.87313@www.mmlab.cse.yzu.edu.tw> Message-ID: <09040423143118.91304@www.mmlab.cse.yzu.edu.tw> On Fri, 3 Apr 2009, Marcel Moolenaar wrote: > On Apr 3, 2009, at 8:15 PM, Tai-hwa Liang wrote: [...] >> g_part_spoiled(ad0s3+00103bf1) >> /dev/ad0s7: FILE SYSTEM CLEAN; SKIPPING CHECKS >> /dev/ad0s7: clean, 4999758 free (51910 frags, 618481 blocks, 0.7% >> fragmentation) >> g_part_taste(PART,ad0s3+00103bf1) >> g_part_taste(PART,ad0s3+00103bf1a) >> g_part_taste(PART,ufsid/46389322544a8c64) >> g_part_spoiled(ad0s3+00103bf1) >> g_part_taste(PART,md0) >> g_part_taste(PART,ufsid/49d71e25191c321d) >> g_part_taste(PART,md0) >> g_part_taste(PART,ufsid/49d73f4d44e77d1b) > > I think your /etc/fstab is wrong. fsck is run on /dev/ad0s7 > and not on /dev/ad0s7a. That's why the geom is spoiled and > gpart show doesn't list the partition. I have to use ad0s7 after moving to GEOM_PART_{BSD,EBR,MBR}; otherwise, booting with with /dev/ad0s7a looks like: g_ignition g_modevent(DISK, LOAD) g_post_event_x(0xc04cd490, 0xc38060a0, 2, 0) g_modevent(PART, LOAD) g_post_event_x(0xc04cd490, 0xc3806090, 2, 0) g_modevent(DEV, LOAD) g_post_event_x(0xc04cd490, 0xc3806080, 2, 0) g_modevent(VFS, LOAD) g_post_event_x(0xc04cd490, 0xc3806040, 2, 0) g_modevent(SWAP, LOAD) g_post_event_x(0xc04cd490, 0xc3806030, 2, 0) g_modevent(LABEL, LOAD) g_post_event_x(0xc04cd490, 0xc3806020, 2, 0) random: g_modevent(ACD, LOAD) g_post_event_x(0xc04cd490, 0xc3806590, 2, 0) g_post_event_x(0xc04cd2c0, 0xc38e5a00, 2, 0) g_post_event_x(0xc04cd2c0, 0xc38e59f0, 2, 0) g_post_event_x(0xc04cd2c0, 0xc38e5820, 2, 0) g_post_event_x(0xc04cd2c0, 0xc38e5700, 2, 0) ata0: Identifying devices: 00000001 ata0: New devices: 00000001 g_load_class(DISK) g_load_class(PART) g_load_class(DEV) g_load_class(VFS) g_load_class(SWAP) g_load_class(LABEL) g_load_usbus0: 12Mbps Full Speed USB v1.0 class(ACD) g_retaste(PART)ad0: setting PIO4 on ICH4 chip g_retaste(PART) g_retaste(PART)ad0: setting UDMA100 on ICH4 chip g_retaste(PART) ad0: 228338850 sectors [226526C/16H/63S] 16 sectors/interrupt 1 depth queue g_post_event_x(0xc04c78b0, 0xc39e4c00, 2, 0) ref 0xc39e4c00 g_post_event_x(0xc04cb510, 0xc384cb00, 2, 0) ref 0xc384cb00 ref 0xc384ca80 GEOM: new disk ad0 g_label_taste(LABEL, ad0) g_detach(0xc39e2c80) g_destroy_consumer(0xc39e2c80) g_destroy_geom(0xc388a280(label:taste)) dev_taste(DEV,ad0) g_part_taste(PART,ad0) g_post_event_x(0xc04cb510, 0xc3ade400, 2, 0) ref 0xc3ade400 ref 0xc39a8a80 g_post_event_x(0xc04cb510, 0xc39a8d80, 2, 0) ref 0xc39a8d80 ref 0xc39a8a80 g_post_event_x(0xc04cb510, 0xc3ade680, 2, 0) ref 0xc3ade680 ref 0xc39a8a80 g_label_taste(LABEL, ad0s1) g_slice_config(ad0s1, 0, 1) g_post_event_x(0xc04cb510, 0xc388a280, 2, 0) ref 0xc388a280 ref 0xc3ade380 GEOM_LABEL: Label for provider ad0s1 is msdosfs/IBM_PRELOAD. g_detach(0xc3ae0c80) g_destroy_consumer(0xc3ae0c80) g_destroy_geom(0xc384cd80(label:taste)) dev_taste(DEV,ad0s1) g_part_taste(PART,ad0s1) g_wither_geom(0xc3ae2700(ad0s1)) g_label_taste(LABEL, ad0s2) g_detach(0xc3ae0b00) g_destroy_consumer(0xc3ae0b00) g_destroy_geom(0xc3ae2600(label:taste)) dev_taste(DEV,ad0s2) g_part_taste(PART,ad0s2) g_post_event_x(0xc04cb510, 0xc3ae2400, 2, 0) ref 0xc3ae2400 ref 0xc3ae2500 g_post_event_x(0xc04cb510, 0xc3ae2300, 2, 0) ref 0xc3ae2300 ref 0xc3ae2500 g_post_event_x(0xc04cb510, 0xc3ae2200, 2, 0) ref 0xc3ae2200 ref 0xc3ae2500 g_post_event_x(0xc04cb510, 0xc3ae2100, 2, 0) ref 0xc3ae2100 ref 0xc3ae2500 g_label_taste(LABEL, ad0s3) g_detach(0xc3ae0880) g_destroy_consumer(0xc3ae0880) g_destroy_geom(0xc3ae2000(label:taste)) dev_taste(DEV,ad0s3) g_part_taste(PART,ad0s3) g_post_event_x(0xc04cb510, 0xc3aded00, 2, 0) ref 0xc3aded00 ref 0xc3adee00 g_post_event_x(0xc04cb510, 0xc3adec00, 2, 0) ref 0xc3adec00 ref 0xc3adee00 g_post_event_x(0xc04cb510, 0xc3adeb00, 2, 0) ref 0xc3adeb00 ref 0xc3adee00 g_post_event_x(0xc04cb510, 0xc3adea00, 2, 0) ref 0xc3adea00 ref 0xc3adee00 g_label_taste(LABEL, msdosfs/IBM_PRELOAD) dev_taste(DEV,msdosfs/IBM_PRELOAD) g_part_taste(PART,msdosfs/IBM_PRELOAD) g_wither_geom(0xc3ade800(msdosfs/IBM_PRELOAD)) g_label_taste(LABEL, ad0s2a) g_slice_config(ad0s2a, 0, 1) g_post_event_x(0xc04cb510, 0xc3ade700, 2, 0) ref 0xc3ade700 ref 0xc3ade780 GEOM_LABEL: Label for provider ad0s2a is ufsid/46387cd616292ca8. g_detach(0xc3ae0580) g_destroy_consumer(0xc3ae0580) g_destroy_geom(0xc3ae2800(label:taste)) dev_taste(DEV,ad0s2a) g_part_taste(PART,ad0s2a) g_wither_geom(0xc3ade600(ad0s2a)) g_label_taste(LABEL, ad0s2b) g_detach(0xc3ae0440) g_destroy_consumer(0xc3ae0440) g_destroy_geom(0xc3ae2600(label:taste)) dev_taste(DEV,ad0s2b) g_part_taste(PART,ad0s2b) g_wither_geom(0xc3ae2680(ad0s2b)) g_label_taste(LABEL, ad0s2d) g_slice_config(ad0s2d, 0, 1) g_post_event_x(0xc04cb510, 0xc3ae2600, 2, 0) ref 0xc3ae2600 ref 0xc3ae2280 GEOM_LABEL: Label for provider ad0s2d is ufsid/46387cd73d66d2ca. g_detach(0xc3ae0340) g_destroy_consumer(0xc3ae0340) g_destroy_geom(0xc384cd80(label:taste)) dev_taste(DEV,ad0s2d) g_part_taste(PART,ad0s2d) g_wither_geom(0xc384cd80(ad0s2d)) g_label_taste(LABEL, ad0s2e) g_slice_config(ad0s2e, 0, 1) g_post_event_x(0xc04cb510, 0xc3aef880, 2, 0) ref 0xc3aef880 ref 0xc3aef900 GEOM_LABEL: Label for provider ad0s2e is ufsid/46387cd6c10fa381. g_detach(0xc3ae0200) g_destroy_consumer(0xc3ae0200) g_destroy_geom(0xc3ae2180(label:taste)) dev_taste(DEV,ad0s2e) g_part_taste(PART,ad0s2e) g_wither_geom(0xc3aef700(ad0s2e)) g_label_taste(LABEL, ad0s3+00000001) g_detach(0xc3ae00c0) g_destroy_consumer(0xc3ae00c0) g_destroy_geom(0xc3aef680(label:taste)) dev_taste(DEV,ad0s3+00000001) g_part_taste(PART,ad0s3+00000001) g_wither_geom(0xc3aef580(ad0s3+00000001)) g_label_taste(LABEL, ad0s3+000410a1) g_slice_config(ad0s3+000410a1, 0, 1) g_post_event_x(0xc04cb510, 0xc3aef380, 2, 0) ref 0xc3aef380 ref 0xc3aef400 GEOM_LABEL: Label for provider ad0s3+000410a1 is msdosfs/ . g_detach(0xc3ae0440) g_destroy_consumer(0xc3ae0440) g_destroy_geom(0xc3aef480(label:taste)) dev_taste(DEV,ad0s3+000410a1) g_part_taste(PART,ad0s3+000410a1) g_wither_geom(0xc3aef200(ad0s3+000410a1)) g_label_taste(LABEL, ad0s3+00103bf1) g_detach(0xc3ae0c80) g_destroy_consumer(0xc3ae0c80) g_destroy_geom(0xc3aef100(label:taste)) dev_taste(DEV,ad0s3+00103bf1) g_part_taste(PART,ad0s3+00103bf1) g_post_event_x(0xc04cb510, 0xc3ae2e00, 2, 0) ref 0xc3ae2e00 ref 0xc3aef000 g_label_taste(LABEL, ad0s3+0017cda1) g_detach(0xc3af6280) g_destroy_consumer(0xc3af6280) g_destroy_geom(0xc3ae2d00(label:taste)) dev_taste(DEV,ad0s3+0017cda1) g_part_taste(PART,ad0s3+0017cda1) g_wither_geom(0xc3ae2c00(ad0s3+0017cda1)) g_label_taste(LABEL, ufsid/46387cd616292ca8) dev_taste(DEV,ufsid/46387cd616292ca8) g_part_taste(PART,ufsid/46387cd616292ca8) g_wither_geom(0xc3ae2a00(ufsid/46387cd616292ca8)) g_label_taste(LABEL, ufsid/46387cd73d66d2ca) dev_taste(DEV,ufsid/46387cd73d66d2ca) g_part_taste(PART,ufsid/46387cd73d66d2ca) g_wither_geom(0xc3ae2880(ufsid/46387cd73d66d2ca)) g_label_taste(LABEL, ufsid/46387cd6c10fa381) dev_taste(DEV,ufsid/46387cd6c10fa381) g_part_taste(PART,ufsid/46387cd6c10fa381) g_wither_geom(0xc3ade980(ufsid/46387cd6c10fa381)) g_label_taste(LABEL, msdosfs/ ) dev_taste(DEV,msdosfs/ ) g_part_taste(PART,msdosfs/ ) g_wither_geom(0xc3ae2d00(msdosfs/ )) g_label_taste(LABEL, ad0s3+00103bf1a) g_slice_config(ad0s3+00103bf1a, 0, 1) g_post_event_x(0xc04cb510, 0xc3aef180, 2, 0) ref 0xc3aef180 ref 0xc3adeb80 GEOM_LABEL: Label for provider ad0s3+00103bf1a is ufsid/46389322544a8c64. g_detach(0xc3ae4d40) g_destroy_consumer(0xc3ae4d40) g_destroy_geom(0xc3aef100(label:taste)) dev_taste(DEV,ad0s3+00103bf1a) g_part_taste(PART,ad0s3+00103bf1a) g_wither_geom(0xc3aef500(ad0s3+00103bf1a)) g_label_taste(LABEL, ufsid/46389322544a8c64) dev_taste(DEV,ufsid/46389322544a8c64) g_part_taste(PART,ufsid/46389322544a8c64) g_wither_geom(0xc3ae2180(ufsid/46389322544a8c64)) g_detach(0xc3ae4bc0) g_destroy_consumer(0xc3ae4bc0) g_destroy_geom(0xc3ae2180(ufsid/46389322544a8c64)) g_detach(0xc3ae4c40) g_destroy_consumer(0xc3ae4c40) g_destroy_geom(0xc3aef500(ad0s3+00103bf1a)) g_detach(0xc3ae4dc0) g_destroy_consumer(0xc3ae4dc0) g_destroy_geom(0xc3ae2d00(msdosfs/ )) g_detach(0xc3ae4e80) g_destroy_consumer(0xc3ae4e80) g_destroy_geom(0xc3ade980(ufsid/46387cd6c10fa381)) g_detach(0xc3af6040) g_destroy_consumer(0xc3af6040) g_destroy_geom(0xc3ae2880(ufsid/46387cd73d66d2ca)) g_detach(0xc3af60c0) g_destroy_consumer(0xc3af60c0) g_destroy_geom(0xc3ae2a00(ufsid/46387cd616292ca8)) g_detach(0xc3af6180) g_destroy_consumer(0xc3af6180) g_destroy_geom(0xc3ae2c00(ad0s3+0017cda1)) g_detach(0xc3ae0b00) g_destroy_consumer(0xc3ae0b00) g_destroy_geom(0xc3aef200(ad0s3+000410a1)) g_detach(0xc3ae0200) g_destroy_consumer(0xc3ae0200) g_destroy_geom(0xc3aef580(ad0s3+00000001)) g_detach(0xc3ae0100) g_destroy_consumer(0xc3ae0100) g_destroy_geom(0xc3aef700(ad0s2e)) g_detach(0xc3ae0240) g_destroy_consumer(0xc3ae0240) g_destroy_geom(0xc384cd80(ad0s2d)) g_detach(0xc3ae0380) g_destroy_consumer(0xc3ae0380) g_destroy_geom(0xc3ae2680(ad0s2b)) g_detach(0xc3ae0480) g_destroy_consumer(0xc3ae0480) g_destroy_geom(0xc3ade600(ad0s2a)) g_detach(0xc3ae0600) g_destroy_consumer(0xc3ae0600) g_destroy_geom(0xc3ade800(msdosfs/IBM_PRELOAD)) g_detach(0xc3ae0b80) g_destroy_consumer(0xc3ae0b80) g_destroy_geom(0xc3ae2700(ad0s1)) g_post_event_x(0xc04863d0, 0xc3ade580, 2, 0) g_post_event_x(0xc04cb510, 0xc384cd80, 2, 0) ref 0xc384cd80 ref 0xc3ae2680 g_label_taste(LABEL, acd0) g_detach(0xc3ae45c0) g_destroy_consumer(0xc3ae45c0) g_destroy_geom(0xc3aef580(label:taste)) dev_taste(DEV,acd0) g_part_taste(PART,acd0) g_post_event_x(0xc04c78b0, 0xc3af9400, 2, 0) ref 0xc3af9400 g_wither_geom(0xc3ae2c00(acd0)) g_post_event_x(0xc04cb510, 0xc3aef480, 2, 0) ref 0xc3aef480 ref 0xc3ae2180 GEOM: new disk cd0 g_label_taste(LABEL, cd0) g_detach(0xc3ae0100) g_destroy_consumer(0xc3ae0100) g_destroy_geom(0xc3aef100(label:taste)) dev_taste(DEV,cd0) scsi_cd.c::ioctl cmd=4400648b error=25 g_part_taste(PART,cd0) (cd0:ata1:0:0:0): error 6 (cd0:ata1:0:0:0): Unretryable Error g_wither_geom(0xc3adea80(cd0)) g_detach(0xc3ae4e80) g_destroy_consumer(0xc3ae4e80) g_destroy_geom(0xc3adea80(cd0)) g_detach(0xc39b5280) g_destroy_consumer(0xc39b5280) g_destroy_geom(0xc3ae2c00(acd0)) Root mount waiting for: usbus3 uhub3: 6 ports with 6 removable, self powered Root mount waiting for: usbus3 ugen3.2: at usbus3 Trying to mount root from ufs:/dev/ad0s2a ct_to_ts([2009-04-04 18:48:32]) = 1238870912.000000000 start_init: trying /sbin/init g_disk_kernedump(ad0, 9971073024, 2147483648) Entropy harvesting: interrupts ethernet point_to_point g_post_event_x(0xc04c7590, 0xc3ae5b00, 2, 262144) g_post_event_x(0xc04c7590, 0xc3ae5b20, 2, 262144) g_post_event_x(0xc04c8a00, 0xc3ae5b40, 2, 262144) g_post_event_x(0xc04c8a00, 0xc3ae5b80, 2, 262144) g_post_event_x(0xc04c8880, 0xc3ae5bc0, 2, 262144) g_post_event_x(0xc04c8880, 0xc3ae5be0, 2, 262144) g_post_event_x(0xc04c8840, 0xc3ae5c60, 2, 262144) g_post_event_x(0xc04c8840, 0xc3ae5c40, 2, 262144) kickstart . g_post_event_x(0xc0665230, 0xdf0d7c64, 2, 262144) g_post_event_x(0xc04cb710, 0xc384cb00, 2, 0) ref 0xc384cb00 g_post_event_x(0xc04cb710, 0xc39a8d80, 2, 0) ref 0xc39a8d80 g_post_event_x(0xc04cb710, 0xc3ae2300, 2, 0) ref 0xc3ae2300 g_post_event_x(0xc04cb710, 0xc3ae2400, 2, 0) ref 0xc3ae2400 GEOM_LABEL: Label ufsid/46387cd616292ca8 removed. g_slice_spoiled(0xc3ae0540/ad0s2a) g_wither_geom(0xc3ade780(ad0s2a)) g_orphan_provider(0xc3ade700(ufsid/46387cd616292ca8), 6) g_orphan_register(ufsid/46387cd616292ca8) g_dev_orphan(0xc3af6100(ufsid/46387cd616292ca8)) g_detach(0xc3af6100) g_destroy_consumer(0xc3af6100) g_destroy_geom(0xc3ae2b00(ufsid/46387cd616292ca8)) g_detach(0xc3ae0540) g_destroy_consumer(0xc3ae0540) g_destroy_geom(0xc3ade780(ad0s2a)) /dev/ad0s2a: FILE SYSTEM CLEAN; SKIPPING CHECKS /dev/ad0s2a: clean, 45406 free (1094 frags, 5539 blocks, 0.6% fragmentation) g_post_event_x(0xc04cb510, 0xc3ae2400, 2, 0) ref 0xc3ae2400 g_label_taste(LABEL, ad0s2a) g_slice_config(ad0s2a, 0, 1) g_post_event_x(0xc04cb510, 0xc3b39900, 2, 0) ref 0xc3b39900 ref 0xc3b31800 GEOM_LABEL: Label for provider ad0s2a is ufsid/46387cd616292ca8. g_detach(0xc3af6480) g_destroy_consumer(0xc3af6480) g_destroy_geom(0xc3b31780(label:taste)) g_part_taste(PART,ad0s2a) g_wither_geom(0xc3b39880(ad0s2a)) g_label_taste(LABEL, ufsid/46387cd616292ca8) dev_taste(DEV,ufsid/46387cd616292ca8) g_part_taste(PART,ufsid/46387cd616292ca8) g_wither_geom(0xc3ade700(ufsid/46387cd616292ca8)) g_detach(0xc3af6580) g_destroy_consumer(0xc3af6580) g_destroy_geom(0xc3ade700(ufsid/46387cd616292ca8)) g_detach(0xc3af6500) g_destroy_consumer(0xc3af6500) g_destroy_geom(0xc3b39880(ad0s2a)) Can't stat /dev/ad0s7a: No such file or directory g_post_event_x(0xc04cb710, 0xc3ae2200, 2, 0) ref 0xc3ae2200 GEOM_LABEL: Label ufsid/46387cd73d66d2ca removed. g_slice_spoiled(0xc3ae0300/ad0s2d) g_wither_geom(0xc3ae2280(ad0s2d)) g_orphan_provider(0xc3ae2600(ufsid/46387cd73d66d2ca), 6) g_orphan_register(ufsid/46387cd73d66d2ca) g_dev_orphan(0xc3af6080(ufsid/46387cd73d66d2ca)) g_detach(0xc3af6080) g_destroy_consumer(0xc3af6080) g_destroy_geom(0xc3ae2980(ufsid/46387cd73d66d2ca)) g_detach(0xc3ae0300) g_destroy_consumer(0xc3ae0300) g_destroy_geom(0xc3ae2280(ad0s2d)) /dev/ad0s2d: FILE SYSTEM CLEAN; SKIPPING CHECKS /dev/ad0s2d: clean, 65349 free (5189 frags, 7520 blocks, 5.5% fragmentation) g_post_event_x(0xc04cb510, 0xc3ae2200, 2, 0) ref 0xc3ae2200 g_label_taste(LABEL, ad0s2d) g_slice_config(ad0s2d, 0, 1) g_post_event_x(0xc04cb510, 0xc3b39880, 2, 0) ref 0xc3b39880 ref 0xc3ae2980 GEOM_LABEL: Label for provider ad0s2d is ufsid/46387cd73d66d2ca. g_detach(0xc3af67c0) g_destroy_consumer(0xc3af67c0) g_destroy_geom(0xc3ae2600(label:taste)) g_part_taste(PART,ad0s2d) g_wither_geom(0xc3ae2600(ad0s2d)) g_label_taste(LABEL, ufsid/46387cd73d66d2ca) dev_taste(DEV,ufsid/46387cd73d66d2ca) g_part_taste(PART,ufsid/46387cd73d66d2ca) g_wither_geom(0xc3b74000(ufsid/46387cd73d66d2ca)) g_detach(0xc3af6900) g_destroy_consumer(0xc3af6900) g_destroy_geom(0xc3b74000(ufsid/46387cd73d66d2ca)) g_detach(0xc3af6840) g_destroy_consumer(0xc3af6840) g_destroy_geom(0xc3ae2600(ad0s2d)) g_post_event_x(0xc04cb710, 0xc3ae2100, 2, 0) ref 0xc3ae2100 GEOM_LABEL: Label ufsid/46387cd6c10fa381 removed. g_slice_spoiled(0xc3ae01c0/ad0s2e) g_wither_geom(0xc3aef900(ad0s2e)) g_orphan_provider(0xc3aef880(ufsid/46387cd6c10fa381), 6) g_orphan_register(ufsid/46387cd6c10fa381) g_dev_orphan(0xc3af6000(ufsid/46387cd6c10fa381)) g_detach(0xc3af6000) g_destroy_consumer(0xc3af6000) g_destroy_geom(0xc3ae2380(ufsid/46387cd6c10fa381)) g_detach(0xc3ae01c0) g_destroy_consumer(0xc3ae01c0) g_destroy_geom(0xc3aef900(ad0s2e)) /dev/ad0s2e: FILE SYSTEM CLEAN; SKIPPING CHECKS /dev/ad0s2e: clean, 689500 free (141532 frags, 68496 blocks, 5.1% fragmentation) g_post_event_x(0xc04cb510, 0xc3ae2100, 2, 0) ref 0xc3ae2100 g_label_taste(LABEL, ad0s2e) g_slice_config(ad0s2e, 0, 1) g_post_event_x(0xc04cb510, 0xc3b73a80, 2, 0) ref 0xc3b73a80 ref 0xc3b73b00 GEOM_LABEL: Label for provider ad0s2e is ufsid/46387cd6c10fa381. g_detach(0xc3af6a40) g_destroy_consumer(0xc3af6a40) g_destroy_geom(0xc3b73b80(label:taste)) g_part_taste(PART,ad0s2e) g_wither_geom(0xc3b73980(ad0s2e)) g_label_taste(LABEL, ufsid/46387cd6c10fa381) dev_taste(DEV,ufsid/46387cd6c10fa381) g_part_taste(PART,ufsid/46387cd6c10fa381) g_wither_geom(0xc3b73800(ufsid/46387cd6c10fa381)) g_detach(0xc3af6b40) g_destroy_consumer(0xc3af6b40) g_destroy_geom(0xc3b73800(ufsid/46387cd6c10fa381)) g_detach(0xc3af6ac0) g_destroy_consumer(0xc3af6ac0) g_destroy_geom(0xc3b73980(ad0s2e)) Can't stat /dev/ad0s7a: No such file or directory THE FOLLOWING FILE SYSTEM HAD AN UNEXPECTED INCONSISTENCY: ufs: /dev/ad0s7a (/home) Unknown error; help! ERROR: ABORTING BOOT (sending SIGTERM to parent)! Apr 5 02:48:33 init: /bin/sh on /etc/rc terminated abnormally, going to single user mode Enter root password, or ^D to go multi-user Password: From xcllnt at mac.com Sat Apr 4 09:09:59 2009 From: xcllnt at mac.com (Marcel Moolenaar) Date: Sat Apr 4 09:10:05 2009 Subject: Removal of GEOM_BSD, GEOM_MBR, GEOM_PC98 and GEOM_SUNLABEL In-Reply-To: <09040423143118.91304@www.mmlab.cse.yzu.edu.tw> References: <20090331155542.74d89d64@ernst.jennejohn.org> <60084D1E-9F64-463A-A8E9-7A237D5C7661@mac.com> <0904011910169.29800@www.mmlab.cse.yzu.edu.tw> <0904020940371.36257@www.mmlab.cse.yzu.edu.tw> <4CCDEFD6-830E-4C8F-B7A2-B7878F8842BE@mac.com> <0904021314574.37737@www.mmlab.cse.yzu.edu.tw> <09040309313414.76643@www.mmlab.cse.yzu.edu.tw> <0904031327195.78401@www.mmlab.cse.yzu.edu.tw> <8583A3BA-2871-4DF4-9792-1031044A4A22@mac.com> <09040315161311.79260@www.mmlab.cse.yzu.edu.tw> <1DDB4728-7742-4265-999F-F1A0FC69F9E4@mac.com> <0904040858433.86299@www.mmlab.cse.yzu.edu.tw> <7AD352A2-BEDD-4DFD-896D-104E6376D887@mac.com> <09040411131618.87313@www.mmlab.cse.yzu.edu.tw> <09040423143118.91304@www.mmlab.cse.yzu.edu.tw> Message-ID: <42E3BB6C-16C7-4211-A4FD-A362383418E9@mac.com> On Apr 4, 2009, at 8:16 AM, Tai-hwa Liang wrote: > I have to use ad0s7 after moving to GEOM_PART_{BSD,EBR,MBR}; > otherwise, > booting with with /dev/ad0s7a looks like: > Can't stat /dev/ad0s7a: No such file or directory It just hit me (doh!). The problem is that /dev/ad0s7 is a compatibility symlink, which exists outside of the GEOM graph. That is, it's a symlink that geom_dev creates and it provides an alternate name to the same "entry point". In your case another GEOM (gpart for the BSD scheme) is stacked onto the gpart GEOM for the EBR scheme) -- with possibly other GEOMs in between. The provider for the 'a' partition is named based on the underlying consumer, which is based on the true name of the GEOM: "ad0s3+00103bf1a". There's no alias for the device node that corresponds to this GEOM and based on some alias that was created by some other geom_dev. This is simply not possible to without messing things up pretty easily. In short: the solution of using a compatibility symlink is flawed at best and useless in the worst case. There's no software fix for it. I think we're left with a simple choice: 1) have EBR create the "old" names and tell the user to reboot every time they make a change in FreeBSD and when booting into FreeBSD after the EBR changed, boot into single user mode to change /etc/fstab and *then* go into multi-user mode, or 2) stick with the new names and tell the user to make this one-time adjustment during upgrades and that's it. If we choose 2, we can argue whether to keep the symlinks or not. I'm sure there's a small group of people for which it works, but I fear the majority of people still have problems. Any thoughts? -- Marcel Moolenaar xcllnt@mac.com From null at pozo.com Sat Apr 4 18:47:12 2009 From: null at pozo.com (Manfred Antar) Date: Sat Apr 4 18:47:19 2009 Subject: /dev/psm0 no longer exists on my current i386 Message-ID: <200904050146.n351knQe001586@pozo.com> Mouse disappeared in current dmesg: psmcpnp0: irq 12 on acpi0 psm0: current command byte:0047 psm0: failed to reset the aux device. no /dev/psm0 after finish boot. xorg starts but no mouse i changed mouse port from /dev/psm0 to /dev/sysmouse, still no mouse. It worked last week with /dev/psm0 ================================== || null@pozo.com || || Ph. (415) 681-6235 || ================================== -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. From dgerow at afflictions.org Sat Apr 4 18:56:51 2009 From: dgerow at afflictions.org (Damian Gerow) Date: Sat Apr 4 18:56:58 2009 Subject: ZFS checksum errors on USB attach (Was: ZFS data error without reasons) In-Reply-To: <20090401234315.GA11125@plebeian.afflictions.org> References: <49BD117B.2080706@163.com> <20090331100328.H46640@rust.salford.ac.uk> <20090401044011.GA51164@plebeian.afflictions.org> <200904010846.55770.hselasky@c2i.net> <20090401121704.GA92522@plebeian.afflictions.org> <20090401234315.GA11125@plebeian.afflictions.org> Message-ID: <20090405015627.GB47968@plebeian.afflictions.org> I've filed kern/133373 to track this. From tmclaugh at sdf.lonestar.org Sat Apr 4 23:39:00 2009 From: tmclaugh at sdf.lonestar.org (Tom McLaughlin) Date: Sat Apr 4 23:39:07 2009 Subject: NFS lockd/statd lock up network connection Message-ID: <49D851FC.4090103@sdf.lonestar.org> Hey, I have a recent -CURRENT box which has a mount exported from an OpenBSD NFS server. Recently I enabled lockd and statd on the machine but this has started to cause the network connection on the machine to lockup. I find the following in dmesg: nfs server exports:/mnt/raid0/net/home: lockd not responding nfs server exports:/mnt/raid0/net/home: lockd not responding nfs server exports:/mnt/raid0/net/home: lockd not responding nfs server exports:/mnt/raid0/net/home: lockd not responding nfs server exports:/mnt/raid0/net/home: lockd not responding nfs server exports:/mnt/raid0/net/home: lockd not responding nfs server exports:/mnt/raid0/net/home: lockd not responding nfs server exports:/mnt/raid0/net/home: lockd not responding NLM: failed to contact remote rpcbind, stat = 5, port = 28416 Additionally I see this when trying to restart netif: em0: Could not setup receive structures I've tried building with NFS_LEGACYRPC but that has not changed anything. Additionally I've tested this on 7-STABLE and while lockd still does not work (so, looks like I'll still have to work around my need for NFS locking) the network connection at least does not lock up. Is what I'm seeing evidence of some further problem? Thanks, tom uname: FreeBSD freebsd-8-amd64.straycat.dhs.org 8.0-CURRENT FreeBSD 8.0-CURRENT #0: Mon Mar 30 02:43:25 EDT 2009 tom@freebsd-8-amd64.straycat.dhs.org:/usr/obj/usr/src/sys/GENERIC amd64 rc.conf: nfs_server_enable="YES" #for tinderbox nfs_server_flags="-u -t -n 20" nfs_reserved_port_only="YES" nfs_client_enable="YES" rpcbind_enable="YES" rpc_lockd_enable="YES" rpc_statd_enable="YES" -- | tmclaugh at sdf.lonestar.org tmclaugh at FreeBSD.org | | FreeBSD http://www.FreeBSD.org | From randy at psg.com Sun Apr 5 01:47:20 2009 From: randy at psg.com (Randy Bush) Date: Sun Apr 5 01:47:27 2009 Subject: new systems using geom mirror hanging Message-ID: i hope to follow up with more useful info. but a number of 8-current systems cvsupped in the last few days are hanging. only those using geom mirror. here is a bit of strange log from one Apr 5 00:13:54 work0 kernel: swap_pager_getswapspace(16): failed Apr 5 00:16:48 work0 kernel: swap_pager_getswapspace(16): failed Apr 5 00:16:48 work0 kernel: swap_pager_getswapspace(12): failed Apr 5 00:16:48 work0 kernel: swap_pager_getswapspace(9): failed Apr 5 00:16:48 work0 kernel: swap_pager_getswapspace(16): failed Apr 5 00:16:48 work0 kernel: swap_pager_getswapspace(12): failed Apr 5 00:16:48 work0 kernel: swap_pager_getswapspace(9): failed Apr 5 00:16:48 work0 kernel: swap_pager_getswapspace(5): failed Apr 5 00:16:48 work0 kernel: swap_pager_getswapspace(16): failedger_getswapspace(3): failed Apr 5 00:16:48 work0 kernel: swap_pager_getswapspace(16): failed Apr 5 00:16:48 work0 kernel: swap_pager_getswapspace(3): failed and another Apr 5 00:08:24 rip kernel: swap_pager: out of swap space Apr 5 00:08:25 rip kernel: swap_pager_getswapspace(2): failed Apr 5 00:08:25 rip kernel: pid 46478 (named), uid 53, was killed: out of swap space these are 4GB systems randy From stb at lassitu.de Sun Apr 5 02:05:27 2009 From: stb at lassitu.de (Stefan Bethke) Date: Sun Apr 5 02:05:34 2009 Subject: panic: vput: negative ref cnt In-Reply-To: <20090404124909.C24261@rust.salford.ac.uk> References: <20090404124909.C24261@rust.salford.ac.uk> Message-ID: <190B8595-BAF8-41F5-B63F-64604672BFD3@lassitu.de> Am 04.04.2009 um 13:55 schrieb Mark Powell: > Hi, > Getting a reproducable panic during backups: > > panic: vput: negative ref cnt > cpuid = 0 > KDB: enter: panic > [thread pid 3521 tid 100374 ] > Stopped at kdb_enter+0x3d: movq $0,0x654104(%rip) > db> bt > Tracing pid 3521 tid 100374 0xffffff008c79e380 > kdb_enter() at kdb_enter+0x3d > panic() at panic+0x176 > vput() at vput+0x10c > dounmount() at dounmount0x421 > unmount() at unmount+0x24b > syscall() at syscall+0x1bf > Xfast_syscall() at Xfast_syscall+0xab > --- syscall (22, FreeBSD ELF64, unmount), rip = 0x800695d7c, rsp = > 0x7fffffffe218, rbp = 0 --- > > My script takes a zfs snapshot, mounts the snapshot, backs it up > using star, then umounts the snapshot. The panic seems to occur on > the umount. This is a different panic from the one I was getting, but appears to occur under the same circumstances. I managed to avoid the panic by keeping the snapshot until the next run of my backup script, and not unmounting anything. See Stefan -- Stefan Bethke Fon +49 151 14070811 From randy at psg.com Sun Apr 5 02:25:20 2009 From: randy at psg.com (Randy Bush) Date: Sun Apr 5 02:25:27 2009 Subject: new systems using geom mirror hanging In-Reply-To: References: Message-ID: and i am getting a lot of Apr 5 09:15:09 rip kernel: GEOM_LABEL: Label ufsid/48adc0bb5c162ca7 removed. Apr 5 09:15:09 rip kernel: GEOM_LABEL: Label ufsid/48adc0bbc77e23dd removed. Apr 5 09:15:09 rip kernel: GEOM_LABEL: Label ufsid/48adc0b15f230b76 removed. Apr 5 09:15:09 rip kernel: GEOM_LABEL: Label ufsid/48adc0b13c88a56a removed. Apr 5 09:16:01 rip kernel: G Apr 5 09:16:01 rip kernel: EOM_LABEL: Label f Apr 5 09:16:01 rip kernel: or provider md0 is Apr 5 09:16:01 rip kernel: ufsid/49d876d1 Apr 5 09:16:01 rip kernel: a55f83f6. Apr 5 09:16:01 rip kernel: Apr 5 09:16:01 rip kernel: GEOM_L Apr 5 09:16:01 rip kernel: ABEL: Lab Apr 5 09:16:01 rip kernel: el ufsid/ Apr 5 09:16:01 rip kernel: 49d876d1 Apr 5 09:16:01 rip kernel: a55f83f6 Apr 5 09:16:01 rip kernel: removed. Apr 5 09:16:01 rip kernel: From nakal at web.de Sun Apr 5 03:13:22 2009 From: nakal at web.de (Martin) Date: Sun Apr 5 03:13:30 2009 Subject: new systems using geom mirror hanging In-Reply-To: References: Message-ID: <20090405121241.0668e978@zelda.local> Am Sun, 05 Apr 2009 18:19:32 +0900 schrieb Randy Bush : > and i am getting a lot of > > Apr 5 09:15:09 rip kernel: GEOM_LABEL: Label ufsid/48adc0bb5c162ca7 > removed. Apr 5 09:15:09 rip kernel: GEOM_LABEL: Label > ufsid/48adc0bbc77e23dd removed. Apr 5 09:15:09 rip kernel: > GEOM_LABEL: Label ufsid/48adc0b15f230b76 removed. Apr 5 09:15:09 rip > kernel: GEOM_LABEL: Label ufsid/48adc0b13c88a56a removed. Apr 5 > 09:16:01 rip kernel: G Apr 5 09:16:01 rip kernel: EOM_LABEL: Label f > Apr 5 09:16:01 rip kernel: or provider md0 is > Apr 5 09:16:01 rip kernel: ufsid/49d876d1 > Apr 5 09:16:01 rip kernel: a55f83f6. > Apr 5 09:16:01 rip kernel: > Apr 5 09:16:01 rip kernel: GEOM_L > Apr 5 09:16:01 rip kernel: ABEL: Lab > Apr 5 09:16:01 rip kernel: el ufsid/ > Apr 5 09:16:01 rip kernel: 49d876d1 > Apr 5 09:16:01 rip kernel: a55f83f6 > Apr 5 09:16:01 rip kernel: removed. > Apr 5 09:16:01 rip kernel: Hi, I want to confirm these "GEOM_LABEL removed" warnings. I don't have any problems starting the system, but I have to admit, I'm worried a bit. What is this? -- Martin From randy at psg.com Sun Apr 5 03:16:03 2009 From: randy at psg.com (Randy Bush) Date: Sun Apr 5 03:16:09 2009 Subject: new systems using geom mirror hanging In-Reply-To: <20090405121241.0668e978@zelda.local> References: <20090405121241.0668e978@zelda.local> Message-ID: > I want to confirm these "GEOM_LABEL removed" warnings. I don't have any > problems starting the system, but I have to admit, I'm worried a bit. no idea. i am assuming a new debug/info feature. note that these systems can not even build a kernel, lock up in seconds. to build a new kernel, i have to boot a dec or jan kernel single user and build using that. randy From ivoras at freebsd.org Sun Apr 5 03:25:53 2009 From: ivoras at freebsd.org (Ivan Voras) Date: Sun Apr 5 03:26:00 2009 Subject: new systems using geom mirror hanging In-Reply-To: References: <20090405121241.0668e978@zelda.local> Message-ID: Randy Bush wrote: >> I want to confirm these "GEOM_LABEL removed" warnings. I don't have any >> problems starting the system, but I have to admit, I'm worried a bit. > > no idea. i am assuming a new debug/info feature. http://lists.freebsd.org/pipermail/freebsd-current/2009-April/005546.html -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 258 bytes Desc: OpenPGP digital signature Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20090405/dcd3fe4c/signature.pgp From bsam at ipt.ru Sun Apr 5 03:27:44 2009 From: bsam at ipt.ru (Boris Samorodov) Date: Sun Apr 5 03:27:53 2009 Subject: Stuck kernel while cleaning up the object tree In-Reply-To: <49D88435.30900@mail.zedat.fu-berlin.de> (O. Hartmann's message of "Sun\, 05 Apr 2009 12\:13\:09 +0200") References: <200904041050.28932.thierry.herbelot@free.fr> <200904041151.18209.thierry.herbelot@free.fr> <10969763@bb.ipt.ru> <49D88435.30900@mail.zedat.fu-berlin.de> Message-ID: <82316530@h30.sp.ipt.ru> On Sun, 05 Apr 2009 12:13:09 +0200 O. Hartmann wrote: > Boris Samorodov wrote: > > On Sat, 4 Apr 2009 11:51:17 +0200 Thierry Herbelot wrote: > > > >> Le Saturday 04 April 2009, Thierry Herbelot a ??crit : > >> > >>> Hello, > >>> > >>> On recent -current machines, I have seen a common pattern, with the machine > >>> being frozen (still responsive to pings, though) in the initial phases of > >>> the buildworld procedure : > >>> > >>> example freeze : > >>> -------------------------------------------------------------- > >>> > >>> > >>>>>> stage 2.1: cleaning up the object tree > >>>>>> > >>> -------------------------------------------------------------- > >>> cd /usr/src; MAKEOBJDIRPREFIX=/usr/obj MACHINE_ARCH=i386 MACHINE=i386 > >>> CPUTYPE= GROFF_BIN_PATH=/usr/obj/usr/src/tmp/legacy/usr/bin > >>> GROFF_FONT_PATH=/usr/obj/usr/src/tmp/legacy/usr/share/groff_font > >>> GROFF_TMAC_PATH=/usr/obj/usr/src/tmp/legacy/usr/share/tmac > >>> _SHLIBDIRPREFIX=/usr/obj/usr/src/tmp VERSION="FreeBSD 8.0-CURRENT i386 > >>> 800074" INSTALL="sh /usr/src/tools/install.sh" > >>> PATH=/usr/obj/usr/src/tmp/legacy/usr/sbin:/usr/obj/usr/src/tmp/legacy/usr/b > >>> in:/usr/obj/usr/src/tmp/legacy/usr/games:/usr/obj/usr/src/tmp/usr/sbin:/usr/ > >>> obj/usr/src/tmp/usr/bin:/usr/obj/usr/src/tmp/usr/games:/sbin:/bin:/usr/sbin: > >>> /usr/bin NO_CTF=1 make -f Makefile.inc1 DESTDIR=/usr/obj/usr/src/tmp > >>> par-cleandir ===> share/info (cleandir) > >>> ===> lib (cleandir) > >>> ===> lib/csu/i386-elf (cleandir) > >>> [type ^T in the console] > >>> load: 0.00 cmd: sh 24587 [*Name Cache] 0.01u 0.00s 0% 1584k > >>> > >>> The other machines also froze while "cleaning up the object tree". > >>> > >>> The machines are configured with serial consoles : I have no kernel stack > >>> backtrace to aid in pinpointing the cause of this freeze. > >>> > >>> Cheers > >>> > >>> TfH > >>> > > > > > >> With a bit more investigation : > >> > > > > > >> on a separate ssh session, top is still live and shows processes stuck as : > >> 24523 root 1 76 0 1888K 764K *Name 1 0:00 0.00% make > >> > > > > > >> on still another machine, running Witnesses (all other machines run with a > >> lean GENERIC, with most of the debuging features commented out) : > >> System call __getcwd returning with the following locks held: > >> shared rw Name Cache (Name Cache) r = 0 (0xc0ee7e1c) locked > >> @ /usr/src/sys/kerne/vfs_cache.c:974 > >> > > > > This is definitely related to: > > SVN rev 190655 on 2009-04-02 21:16:20Z by peter > > (peter@ CCed) > > > > > >> panic: witness_warn > >> cpuid = 0 > >> KDB: enter: panic > Is there a fix in sight soon? I do have this error/fault/lockup now on > ALL FreeBSD 8.0-CURRENT/amd64 machines I have. I've reverted SVN rev 190655 and it's OK for half a day now. WBR -- Boris Samorodov (bsam) Research Engineer, http://www.ipt.ru Telephone & Internet SP FreeBSD committer, http://www.FreeBSD.org The Power To Serve From randy at psg.com Sun Apr 5 03:42:45 2009 From: randy at psg.com (Randy Bush) Date: Sun Apr 5 03:42:52 2009 Subject: new systems using geom mirror hanging In-Reply-To: References: <20090405121241.0668e978@zelda.local> Message-ID: > note that these systems can not even build a kernel, lock up in > seconds. to build a new kernel, i have to boot a dec or jan kernel > single user and build using that. doh, these are also all am64 randy From stb at lassitu.de Sun Apr 5 03:47:12 2009 From: stb at lassitu.de (Stefan Bethke) Date: Sun Apr 5 03:47:19 2009 Subject: enabling pf causes socket panics? In-Reply-To: <4A766A21-7E01-46DF-98EB-A8BABC248AAD@lassitu.de> References: <4A766A21-7E01-46DF-98EB-A8BABC248AAD@lassitu.de> Message-ID: <1EB12CA7-D811-434D-8F21-BFDB819918CB@lassitu.de> Am 28.03.2009 um 10:44 schrieb Stefan Bethke: > With pf enabled, I get panics after only a few minutes of light > traffic trought the machine. These two I could capture on the > console (no dumps written because of mirrored swap): > > panic: sbsndptr: sockbuf 0xffffff0010005b60 and mbuf > 0xffffff0004cdfe00 clashing > cpuid = 1 > KDB: enter: panic > [thread pid 739 tid 100148 ] > Stopped at kdb_enter+0x3d: movq $0,0x47ed48(%rip) > db> > > panic: sbflush_internal: cc 60 || mb 0 || mbcnt 0 > cpuid = 0 > KDB: enter: panic > [thread pid 1696 tid 100125 ] > Stopped at kdb_enter+0x3d: movq $0,0x47ed48(%rip) > db> bt > Tracing pid 1696 tid 100125 td 0xffffff000499a000 > kdb_enter() at kdb_enter+0x3d > panic() at panic+0x17b > sbflush_internal() at sbflush_internal+0x64 > sbrelease_internal() at sbrelease_internal+0x1c > sofree() at sofree+0x107 > soclose() at soclose+0x118 > _fdrop() at _fdrop+0x23 > closef() at closef+0x4c > kern_close() at kern_close+0x110 > syscall() at syscall+0x1a5 > Xfast_syscall() at Xfast_syscall+0xab > --- syscall (6, FreeBSD ELF64, close), rip = 0x800d3c89c, rsp = > 0x7fffffffcbc8, rbp = 0x1b --- > > Before enabling pf, the system ran fully stable for two weeks. > Disabling pf again (pfctl -d) makes it stable again. I've made two changes which apparently stop the panic from triggering. This system has a bridge(4) consisting of one vlan(4) and one tap(4) interface; the bridge has the IP address assigned (instead of one of the member interfaces). I've disabled net.link.bridge.pfil_member=0, so that packets are not filtered twice (once on the member interface and once on the bridge interface). I've also removed rules from pf.conf that referenced the vlan and the tap interface. Stefan -- Stefan Bethke Fon +49 151 14070811 From M.S.Powell at salford.ac.uk Sun Apr 5 04:15:09 2009 From: M.S.Powell at salford.ac.uk (Mark Powell) Date: Sun Apr 5 04:15:16 2009 Subject: panic: vput: negative ref cnt In-Reply-To: <190B8595-BAF8-41F5-B63F-64604672BFD3@lassitu.de> References: <20090404124909.C24261@rust.salford.ac.uk> <190B8595-BAF8-41F5-B63F-64604672BFD3@lassitu.de> Message-ID: <20090405120658.A24261@rust.salford.ac.uk> On Sun, 5 Apr 2009, Stefan Bethke wrote: Stefan, Thanks for the input. > Am 04.04.2009 um 13:55 schrieb Mark Powell: >> My script takes a zfs snapshot, mounts the snapshot, backs it up using >> star, then umounts the snapshot. The panic seems to occur on the umount. > > This is a different panic from the one I was getting, but appears to occur > under the same circumstances. > > I managed to avoid the panic by keeping the snapshot until the next run of my > backup script, and not unmounting anything. Yeah, I got around it by avoiding the unmount. My script dates from 7-STABLE days, where a zfs bug caused the automounted snapdir e.g. .zfs/snapshot/star_L0_2009-04-04-16:57, to be missing a '..' entry. That prevented star from detecting that I was performing a true full backup. Thus my script directly mounted the snapshot to get a proper fs with a '..' entry and unmounted it when finished. Now the included version of zfs in 8-CURRENT doesn't have that bug any longer. So I've reverted to backing up the automounted snapdir. Consequently as I don't perform a mount I don't have to unmount either, effectively working around the bug. > See > Do you know if a PR has been submitted for this one? Cheers. -- Mark Powell - UNIX System Administrator - The University of Salford Information & Learning Services, Clifford Whitworth Building, Salford University, Manchester, M5 4WT, UK. Tel: +44 161 295 6843 Fax: +44 161 295 5888 www.pgp.com for PGP key From barney_cordoba at yahoo.com Sun Apr 5 04:18:10 2009 From: barney_cordoba at yahoo.com (Barney Cordoba) Date: Sun Apr 5 04:18:17 2009 Subject: Kip Macy In-Reply-To: Message-ID: <11619.11192.qm@web63903.mail.re1.yahoo.com> --- On Tue, 3/31/09, Barrett Lyon wrote: > From: Barrett Lyon > Subject: Kip Macy > To: freebsd-current@freebsd.org > Date: Tuesday, March 31, 2009, 7:24 PM > I'm sure this is the wrong place to post this, but I > thought I would share anyway: > > http://digg.com/linux_unix/FreeBSD_developer_s_life_destroyed_by_squatter_from_hell > > It's Kip's story from the other side, I thought > this community may like to read it and spread the digg > story. > > -Barrett I hate to interject politics into this, but this is what the entire country will be like if Obama has his way. G*d help us. Barney From randy at psg.com Sun Apr 5 04:21:56 2009 From: randy at psg.com (Randy Bush) Date: Sun Apr 5 04:22:02 2009 Subject: Kip Macy In-Reply-To: <11619.11192.qm@web63903.mail.re1.yahoo.com> References: <11619.11192.qm@web63903.mail.re1.yahoo.com> Message-ID: > I hate to interject politics into this, but this is what the entire > country will be like if Obama has his way. G*d help us. and don't forget the black helicopters from hawai`i and the zyklon b he and his muslim friends have stored under the white house? effing wingnuts! From ohartman at mail.zedat.fu-berlin.de Sun Apr 5 03:13:15 2009 From: ohartman at mail.zedat.fu-berlin.de (O. Hartmann) Date: Sun Apr 5 04:27:56 2009 Subject: Stuck kernel while cleaning up the object tree In-Reply-To: <10969763@bb.ipt.ru> References: <200904041050.28932.thierry.herbelot@free.fr> <200904041151.18209.thierry.herbelot@free.fr> <10969763@bb.ipt.ru> Message-ID: <49D88435.30900@mail.zedat.fu-berlin.de> Boris Samorodov wrote: > On Sat, 4 Apr 2009 11:51:17 +0200 Thierry Herbelot wrote: > >> Le Saturday 04 April 2009, Thierry Herbelot a ??crit : >> >>> Hello, >>> >>> On recent -current machines, I have seen a common pattern, with the machine >>> being frozen (still responsive to pings, though) in the initial phases of >>> the buildworld procedure : >>> >>> example freeze : >>> -------------------------------------------------------------- >>> >>> >>>>>> stage 2.1: cleaning up the object tree >>>>>> >>> -------------------------------------------------------------- >>> cd /usr/src; MAKEOBJDIRPREFIX=/usr/obj MACHINE_ARCH=i386 MACHINE=i386 >>> CPUTYPE= GROFF_BIN_PATH=/usr/obj/usr/src/tmp/legacy/usr/bin >>> GROFF_FONT_PATH=/usr/obj/usr/src/tmp/legacy/usr/share/groff_font >>> GROFF_TMAC_PATH=/usr/obj/usr/src/tmp/legacy/usr/share/tmac >>> _SHLIBDIRPREFIX=/usr/obj/usr/src/tmp VERSION="FreeBSD 8.0-CURRENT i386 >>> 800074" INSTALL="sh /usr/src/tools/install.sh" >>> PATH=/usr/obj/usr/src/tmp/legacy/usr/sbin:/usr/obj/usr/src/tmp/legacy/usr/b >>> in:/usr/obj/usr/src/tmp/legacy/usr/games:/usr/obj/usr/src/tmp/usr/sbin:/usr/ >>> obj/usr/src/tmp/usr/bin:/usr/obj/usr/src/tmp/usr/games:/sbin:/bin:/usr/sbin: >>> /usr/bin NO_CTF=1 make -f Makefile.inc1 DESTDIR=/usr/obj/usr/src/tmp >>> par-cleandir ===> share/info (cleandir) >>> ===> lib (cleandir) >>> ===> lib/csu/i386-elf (cleandir) >>> [type ^T in the console] >>> load: 0.00 cmd: sh 24587 [*Name Cache] 0.01u 0.00s 0% 1584k >>> >>> The other machines also froze while "cleaning up the object tree". >>> >>> The machines are configured with serial consoles : I have no kernel stack >>> backtrace to aid in pinpointing the cause of this freeze. >>> >>> Cheers >>> >>> TfH >>> > > >> With a bit more investigation : >> > > >> on a separate ssh session, top is still live and shows processes stuck as : >> 24523 root 1 76 0 1888K 764K *Name 1 0:00 0.00% make >> > > >> on still another machine, running Witnesses (all other machines run with a >> lean GENERIC, with most of the debuging features commented out) : >> System call __getcwd returning with the following locks held: >> shared rw Name Cache (Name Cache) r = 0 (0xc0ee7e1c) locked >> @ /usr/src/sys/kerne/vfs_cache.c:974 >> > > This is definitely related to: > SVN rev 190655 on 2009-04-02 21:16:20Z by peter > (peter@ CCed) > > >> panic: witness_warn >> cpuid = 0 >> KDB: enter: panic >> > > > WBR > Is there a fix in sight soon? I do have this error/fault/lockup now on ALL FreeBSD 8.0-CURRENT/amd64 machines I have. Regards, Oliver From stb at lassitu.de Sun Apr 5 04:34:29 2009 From: stb at lassitu.de (Stefan Bethke) Date: Sun Apr 5 04:34:36 2009 Subject: panic: vput: negative ref cnt In-Reply-To: <20090405120658.A24261@rust.salford.ac.uk> References: <20090404124909.C24261@rust.salford.ac.uk> <190B8595-BAF8-41F5-B63F-64604672BFD3@lassitu.de> <20090405120658.A24261@rust.salford.ac.uk> Message-ID: <98479514-21F9-4267-AD9F-DC697B7E0E0E@lassitu.de> Am 05.04.2009 um 13:15 schrieb Mark Powell: > On Sun, 5 Apr 2009, Stefan Bethke wrote: > > Stefan, > Thanks for the input. > >> Am 04.04.2009 um 13:55 schrieb Mark Powell: >>> My script takes a zfs snapshot, mounts the snapshot, backs it up >>> using star, then umounts the snapshot. The panic seems to occur on >>> the umount. >> >> This is a different panic from the one I was getting, but appears >> to occur under the same circumstances. >> >> I managed to avoid the panic by keeping the snapshot until the next >> run of my backup script, and not unmounting anything. > > Yeah, I got around it by avoiding the unmount. > My script dates from 7-STABLE days, where a zfs bug caused the > automounted snapdir e.g. .zfs/snapshot/star_L0_2009-04-04-16:57, to > be missing a '..' entry. That prevented star from detecting that I > was performing a true full backup. Thus my script directly mounted > the snapshot to get a proper fs with a '..' entry and unmounted it > when finished. > Now the included version of zfs in 8-CURRENT doesn't have that bug > any longer. So I've reverted to backing up the automounted snapdir. > Consequently as I don't perform a mount I don't have to unmount > either, effectively working around the bug. > >> See > > > > Do you know if a PR has been submitted for this one? When I lasted searched for it about six weeks ago, I couldn't find any. I wanted to reproduce the panic in VMware first to gather more details, but I've been unsuccessful in triggering it there at all. Maybe I need to switch my production boxes over to VMware :-) Stefan -- Stefan Bethke Fon +49 151 14070811 From kostikbel at gmail.com Sun Apr 5 04:41:57 2009 From: kostikbel at gmail.com (Kostik Belousov) Date: Sun Apr 5 04:42:04 2009 Subject: Stuck kernel while cleaning up the object tree In-Reply-To: <49D88435.30900@mail.zedat.fu-berlin.de> References: <200904041050.28932.thierry.herbelot@free.fr> <200904041151.18209.thierry.herbelot@free.fr> <10969763@bb.ipt.ru> <49D88435.30900@mail.zedat.fu-berlin.de> Message-ID: <20090405114150.GM31897@deviant.kiev.zoral.com.ua> On Sun, Apr 05, 2009 at 12:13:09PM +0200, O. Hartmann wrote: > Boris Samorodov wrote: > > On Sat, 4 Apr 2009 11:51:17 +0200 Thierry Herbelot wrote: > > > >> Le Saturday 04 April 2009, Thierry Herbelot a ??crit : > >> > >>> Hello, > >>> > >>> On recent -current machines, I have seen a common pattern, with the machine > >>> being frozen (still responsive to pings, though) in the initial phases of > >>> the buildworld procedure : > >>> > >>> example freeze : > >>> -------------------------------------------------------------- > >>> > >>> > >>>>>> stage 2.1: cleaning up the object tree > >>>>>> > >>> -------------------------------------------------------------- > >>> cd /usr/src; MAKEOBJDIRPREFIX=/usr/obj MACHINE_ARCH=i386 MACHINE=i386 > >>> CPUTYPE= GROFF_BIN_PATH=/usr/obj/usr/src/tmp/legacy/usr/bin > >>> GROFF_FONT_PATH=/usr/obj/usr/src/tmp/legacy/usr/share/groff_font > >>> GROFF_TMAC_PATH=/usr/obj/usr/src/tmp/legacy/usr/share/tmac > >>> _SHLIBDIRPREFIX=/usr/obj/usr/src/tmp VERSION="FreeBSD 8.0-CURRENT i386 > >>> 800074" INSTALL="sh /usr/src/tools/install.sh" > >>> PATH=/usr/obj/usr/src/tmp/legacy/usr/sbin:/usr/obj/usr/src/tmp/legacy/usr/b > >>> in:/usr/obj/usr/src/tmp/legacy/usr/games:/usr/obj/usr/src/tmp/usr/sbin:/usr/ > >>> obj/usr/src/tmp/usr/bin:/usr/obj/usr/src/tmp/usr/games:/sbin:/bin:/usr/sbin: > >>> /usr/bin NO_CTF=1 make -f Makefile.inc1 DESTDIR=/usr/obj/usr/src/tmp > >>> par-cleandir ===> share/info (cleandir) > >>> ===> lib (cleandir) > >>> ===> lib/csu/i386-elf (cleandir) > >>> [type ^T in the console] > >>> load: 0.00 cmd: sh 24587 [*Name Cache] 0.01u 0.00s 0% 1584k > >>> > >>> The other machines also froze while "cleaning up the object tree". > >>> > >>> The machines are configured with serial consoles : I have no kernel stack > >>> backtrace to aid in pinpointing the cause of this freeze. > >>> > >>> Cheers > >>> > >>> TfH > >>> > > > > > >> With a bit more investigation : > >> > > > > > >> on a separate ssh session, top is still live and shows processes stuck as : > >> 24523 root 1 76 0 1888K 764K *Name 1 0:00 0.00% make > >> > > > > > >> on still another machine, running Witnesses (all other machines run with a > >> lean GENERIC, with most of the debuging features commented out) : > >> System call __getcwd returning with the following locks held: > >> shared rw Name Cache (Name Cache) r = 0 (0xc0ee7e1c) locked > >> @ /usr/src/sys/kerne/vfs_cache.c:974 > >> > > > > This is definitely related to: > > SVN rev 190655 on 2009-04-02 21:16:20Z by peter > > (peter@ CCed) > > > > > >> panic: witness_warn > >> cpuid = 0 > >> KDB: enter: panic > >> > > > > > > WBR > > > Is there a fix in sight soon? I do have this error/fault/lockup now on > ALL FreeBSD 8.0-CURRENT/amd64 machines I have. The commit was reverted yesterday. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20090405/cb8a231b/attachment.pgp From barney_cordoba at yahoo.com Sun Apr 5 05:01:21 2009 From: barney_cordoba at yahoo.com (Barney Cordoba) Date: Sun Apr 5 05:01:29 2009 Subject: pci_alloc_resource patch In-Reply-To: <20090401065430.GA12025@server.vk2pj.dyndns.org> Message-ID: <688193.97950.qm@web63901.mail.re1.yahoo.com> --- On Wed, 4/1/09, Peter Jeremy wrote: > From: Peter Jeremy > Subject: Re: pci_alloc_resource is broken > To: "Barney Cordoba" > Cc: "John Baldwin" , freebsd-current@freebsd.org > Date: Wednesday, April 1, 2009, 2:54 AM > On 2009-Mar-31 10:55:26 -0700, Barney Cordoba > wrote: > >Its really you who is being condescending. > > You _really_ need to learn some manners. Despite your > goading, > John has remained polite and helpful. > > >in business for 20 years with 3000 active customers > that > > Given your attitude, I'm surprised you have _any_ > customers. > I presume you have other minions who actually interact with > them. > > > If you were Bill Gates > >I'd accept that. But you're a programmer. > > More insults. BTW, I suspect Bill Gates considers himself > a > programmer - he used to be a fairly good one. Bill Gates is a successful businessman. John Baldwin is not. So his "advice" about what is commercially acceptable has zero value. I'm sorry if that went over your head. > > >Now is a resource in use a "fatal" system > error? > > That depends on the resource but, possibly, yes. > > >Face it please. You replaced one bug with another. If > you spent half the > >effort doing it correctly as you are spending defending > what you've done > >we'd all be a lot happier. > > If you spent as much time helping the project by providing > patches or > constructive input as you do insulting the developers, > we'd all be a > lot happier. > > -- > Peter Jeremy If the developer's fragile egos won't allow them to admit that their code is wrong or deficient, then whats the point of spending my time doing PRs or submitting patches? John believes that the OS is his personal toy and that putting panics into his code is a good thing. If you can't get him to admit that his coding philosophy is part of the problem, then you have no chance of fixing it with a PR. So Peter, I assume you agree that the panic in pci_alloc_resource() is appropriate instead of the expected NULL return? Or are you just blindly bloviating for your friend? Here's your fix. Now a driver that attempts to re-allocate a busy resource gets a nice "Unable to allocate bus resource: memory" message instead of a system panic. The way a good OS is supposed to work. I really don't have time to do PRs so you can do it yourself. 3539,3540d3538 < < 3594,3595c3592,3599 < if (rle != NULL && rle->res != NULL && < rman_get_device(rle->res) == dev) { --- > if (rle != NULL && rle->res != NULL){ > if (rman_get_device(rle->res) != dev){ > if (bootverbose){ > device_printf(child, > "pci_alloc_resource: resource busy\n"); > } > return(NULL); > } Barney From jrh29 at alumni.cwru.edu Sun Apr 5 05:43:20 2009 From: jrh29 at alumni.cwru.edu (Justin Hibbits) Date: Sun Apr 5 05:43:26 2009 Subject: pci_alloc_resource patch In-Reply-To: <688193.97950.qm@web63901.mail.re1.yahoo.com> References: <20090401065430.GA12025@server.vk2pj.dyndns.org> <688193.97950.qm@web63901.mail.re1.yahoo.com> Message-ID: <20090405124341.GB22912@narn.knownspace> On Sun, Apr 05, 2009 at 05:01:17AM -0700, Barney Cordoba wrote: > Bill Gates is a successful businessman. John Baldwin is not. So his > "advice" about what is commercially acceptable has zero value. I'm > sorry if that went over your head. Dude, insults will get you nowhere. Also, you do realize that a large number of developers are paid employees doing work for commercial entities, right? So if John Baldwin says something is commercially acceptable, he may very well be right. Then again, he could be wrong. It depends entirely on the field. Maybe in the consumer sector a driver failure should be tolerated, but in the server and high performance computing sector a driver failure could very well be catastrophic. Not all commercial sectors are created equal. Also, John gave an option of how to do what you need, and pointed to prior art as why he did it. You should be basing your arguments on actual research and not just on "because I want to do it this way". > > If the developer's fragile egos won't allow them to admit that their > code is wrong or deficient, then whats the point of spending my time > doing PRs or submitting patches? John believes that the OS is his > personal toy and that putting panics into his code is a good thing. If > you can't get him to admit that his coding philosophy is part of the > problem, then you have no chance of fixing it with a PR. > > > So Peter, I assume you agree that the panic in pci_alloc_resource() > is appropriate instead of the expected NULL return? Or are you just > blindly bloviating for your friend? > > Here's your fix. Now a driver that attempts to re-allocate a busy resource > gets a nice "Unable to allocate bus resource: memory" message instead of > a system panic. The way a good OS is supposed to work. I really > don't have time to do PRs so you can do it yourself. If you have the time to post to the list with such eloquent hostility, you certainly have time to file a PR. It takes only a few minutes, less than half the time it takes to publicly insult the developers. Also, you should provide a sufficient reason for the PR being needed, and "because I said so" is not a sufficient reason. > > Barney - Justin From astrodog at gmail.com Sun Apr 5 05:56:44 2009 From: astrodog at gmail.com (Astrodog) Date: Sun Apr 5 05:56:51 2009 Subject: Kip Macy In-Reply-To: <11619.11192.qm@web63903.mail.re1.yahoo.com> References: <11619.11192.qm@web63903.mail.re1.yahoo.com> Message-ID: <2fd864e0904050556r78349ad7x47b1de102e916d74@mail.gmail.com> On Sun, Apr 5, 2009 at 6:18 AM, Barney Cordoba wrote: > > > > > --- On Tue, 3/31/09, Barrett Lyon wrote: > >> From: Barrett Lyon >> Subject: Kip Macy >> To: freebsd-current@freebsd.org >> Date: Tuesday, March 31, 2009, 7:24 PM >> I'm sure this is the wrong place to post this, but I >> thought I would share anyway: >> >> http://digg.com/linux_unix/FreeBSD_developer_s_life_destroyed_by_squatter_from_hell >> >> It's Kip's story from the other side, I thought >> this community may like to read it and spread the digg >> story. >> >> -Barrett > > I hate to interject politics into this, but this is what the entire > country will be like if Obama has his way. G*d help us. > > Barney re: The entire discussion... this should probably be on -chat, not -current. re: The political statement above, the fact that you are bringing politics into this, on -current, no less, seems to indicate that you don't actually "hate to interject politics" into anything. If people want to keep this discussion going, how about moving over to -chat? --- Harrison From null at pozo.com Sun Apr 5 06:32:38 2009 From: null at pozo.com (Manfred Antar) Date: Sun Apr 5 06:32:45 2009 Subject: /dev/psm0 no longer exists on my current i386 In-Reply-To: <200904050146.n351knQe001586@pozo.com> References: <200904050146.n351knQe001586@pozo.com> Message-ID: <200904051332.n35DWI1Y081196@pozo.com> At 06:46 PM 4/4/2009, Manfred Antar wrote: >Mouse disappeared in current > >dmesg: >psmcpnp0: irq 12 on acpi0 >psm0: current command byte:0047 >psm0: failed to reset the aux device. > >no /dev/psm0 after finish boot. >xorg starts but no mouse >i changed mouse port from /dev/psm0 to /dev/sysmouse, still no mouse. >It worked last week with /dev/psm0 My Bad, I powered the machine off and rebooted. /dev/psm0 is there now ================================== || null@pozo.com || || Ph. (415) 681-6235 || ================================== -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. From onemda at gmail.com Sun Apr 5 08:11:33 2009 From: onemda at gmail.com (Paul B. Mahol) Date: Sun Apr 5 08:11:39 2009 Subject: new systems using geom mirror hanging In-Reply-To: References: Message-ID: <3a142e750904050749q1fd5ff6axfb24c80b431854fb@mail.gmail.com> On 4/5/09, Randy Bush wrote: > > > i hope to follow up with more useful info. but a number of 8-current > systems cvsupped in the last few days are hanging. only those using > geom mirror. > > here is a bit of strange log from one > > Apr 5 00:13:54 work0 kernel: swap_pager_getswapspace(16): failed > Apr 5 00:16:48 work0 kernel: swap_pager_getswapspace(16): failed > Apr 5 00:16:48 work0 kernel: swap_pager_getswapspace(12): failed > Apr 5 00:16:48 work0 kernel: swap_pager_getswapspace(9): failed > Apr 5 00:16:48 work0 kernel: swap_pager_getswapspace(16): failed > Apr 5 00:16:48 work0 kernel: swap_pager_getswapspace(12): failed > Apr 5 00:16:48 work0 kernel: swap_pager_getswapspace(9): failed > Apr 5 00:16:48 work0 kernel: swap_pager_getswapspace(5): failed > Apr 5 00:16:48 work0 kernel: swap_pager_getswapspace(16): > failedger_getswapspace(3): failed > Apr 5 00:16:48 work0 kernel: swap_pager_getswapspace(16): failed > Apr 5 00:16:48 work0 kernel: swap_pager_getswapspace(3): failed > > and another > > Apr 5 00:08:24 rip kernel: swap_pager: out of swap space > Apr 5 00:08:25 rip kernel: swap_pager_getswapspace(2): failed > Apr 5 00:08:25 rip kernel: pid 46478 (named), uid 53, was killed: out of > swap space Does this mean that something eats RAM? 'Hanging' is/can be normal if swap is used to much. -- Paul From manfred.lotz at arcor.de Sun Apr 5 09:10:01 2009 From: manfred.lotz at arcor.de (Manfred Lotz) Date: Sun Apr 5 09:10:08 2009 Subject: xorg loops Message-ID: <49D8D03B.8090302@arcor.de> Hi all, Using 8 current from time to time I have an xorg problem. Getting millions of those messages (II) Mouse autoprobe: Changing protocol to ExplorerPS/2 (II) Mouse autoprobe: Changing protocol to ImPS/2 the system is unusable. No response from keyboard or mouse any more. Any idea, what I can do to prevent this from happining? -- Manfred From onemda at gmail.com Sun Apr 5 09:19:18 2009 From: onemda at gmail.com (Paul B. Mahol) Date: Sun Apr 5 09:19:25 2009 Subject: xorg loops In-Reply-To: <49D8D03B.8090302@arcor.de> References: <49D8D03B.8090302@arcor.de> Message-ID: <3a142e750904050919l1388b559t9bbd751546e239e7@mail.gmail.com> On 4/5/09, Manfred Lotz wrote: > Hi all, > Using 8 current from time to time I have an xorg problem. > > Getting millions of those messages > > (II) Mouse autoprobe: Changing protocol to ExplorerPS/2 > (II) Mouse autoprobe: Changing protocol to ImPS/2 > > the system is unusable. No response from keyboard or mouse any more. > > > > Any idea, what I can do to prevent this from happining? Disable hal if it is enabled? -- Paul From manfred.lotz at arcor.de Sun Apr 5 09:48:55 2009 From: manfred.lotz at arcor.de (Manfred Lotz) Date: Sun Apr 5 09:49:01 2009 Subject: xorg loops In-Reply-To: <3a142e750904050919l1388b559t9bbd751546e239e7@mail.gmail.com> References: <49D8D03B.8090302@arcor.de> <3a142e750904050919l1388b559t9bbd751546e239e7@mail.gmail.com> Message-ID: <49D8E0F4.6050200@arcor.de> Paul B. Mahol wrote: > On 4/5/09, Manfred Lotz wrote: > >> Hi all, >> Using 8 current from time to time I have an xorg problem. >> >> Getting millions of those messages >> >> (II) Mouse autoprobe: Changing protocol to ExplorerPS/2 >> (II) Mouse autoprobe: Changing protocol to ImPS/2 >> >> the system is unusable. No response from keyboard or mouse any more. >> >> >> >> Any idea, what I can do to prevent this from happining? >> > > Disable hal if it is enabled? > > hal was enabled. I disabled it. Hopefully, it'll help. -- Thanks, Manfred -- Manfred From tinderbox at freebsd.org Sun Apr 5 10:01:59 2009 From: tinderbox at freebsd.org (FreeBSD Tinderbox) Date: Sun Apr 5 10:02:33 2009 Subject: [head tinderbox] failure on sparc64/sun4v Message-ID: <20090405170153.E5FD57302F@freebsd-current.sentex.ca> TB --- 2009-04-05 16:01:08 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2009-04-05 16:01:08 - starting HEAD tinderbox run for sparc64/sun4v TB --- 2009-04-05 16:01:08 - cleaning the object tree TB --- 2009-04-05 16:01:41 - cvsupping the source tree TB --- 2009-04-05 16:01:41 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/sparc64/sun4v/supfile TB --- 2009-04-05 16:01:49 - building world TB --- 2009-04-05 16:01:49 - MAKEOBJDIRPREFIX=/obj TB --- 2009-04-05 16:01:49 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-04-05 16:01:49 - TARGET=sun4v TB --- 2009-04-05 16:01:49 - TARGET_ARCH=sparc64 TB --- 2009-04-05 16:01:49 - TZ=UTC TB --- 2009-04-05 16:01:49 - __MAKE_CONF=/dev/null TB --- 2009-04-05 16:01:49 - cd /src TB --- 2009-04-05 16:01:49 - /usr/bin/make -B buildworld >>> World build started on Sun Apr 5 16:01:50 UTC 2009 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything [...] /src/sbin/routed/if.c:703: warning: cast increases required alignment of target type /src/sbin/routed/if.c:707: warning: cast increases required alignment of target type /src/sbin/routed/if.c:716: warning: cast increases required alignment of target type /src/sbin/routed/if.c:774: warning: cast increases required alignment of target type /src/sbin/routed/if.c:815: warning: cast increases required alignment of target type /src/sbin/routed/if.c:828: warning: cast increases required alignment of target type /src/sbin/routed/if.c:843: warning: cast increases required alignment of target type /src/sbin/routed/if.c:862: warning: cast increases required alignment of target type *** Error code 1 Stop in /src/sbin/routed. *** Error code 1 Stop in /obj/sun4v/src/rescue/rescue. *** Error code 1 Stop in /src/rescue/rescue. *** Error code 1 Stop in /src/rescue. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-04-05 17:01:53 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-04-05 17:01:53 - ERROR: failed to build world TB --- 2009-04-05 17:01:53 - 3061.64 user 309.80 system 3645.61 real http://tinderbox.des.no/tinderbox-head-HEAD-sparc64-sun4v.full From chuckr at telenix.org Sun Apr 5 10:35:48 2009 From: chuckr at telenix.org (Chuck Robey) Date: Sun Apr 5 10:35:55 2009 Subject: comparing svn and cvs somewhat Message-ID: <49D8EC20.70700@telenix.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I have gotten a local copy of the svn repo going on my home here, by using svnsync, which seems (by what I've read and been told) to be the right method. I'm wondering about a feature that is there for cvs, in cvsup, but which seems to be missing in svnsync for svn. What I'm after is a much better way to maintain a local repo than what I'm seeing now in maintaining my svn repo, with svnsync. The main feature that I think I'm missing is the ability to be able to compare files on a central server (something serving all FreeBSDers) to files on everybody's personal repo, and to automatically update them if there isn't a perfect comparison. I'm not talking about the varying ways that your repo might get damaged, but I think that svnsync only knows that you have a particular revision number, not that the file is correct. If your repo gets damage, I think that nothing exists to automatically fix it. So, if this feature IS something that's already available in svn, I'd like to here a summary of what tool to use the how to do it, so I can verify myself that what I'm thinking about already exists. That'd free me to begin writing software, to see if I could implement such a feature. I'm not truly certain of this, but it seems to me that implementing such a feature, using something like Python, would be very easy to do. Could end up with a svn version of cvs's cvsup. Maybe, call it svnup? I'm terrible at names, if you think that name makes no sense, please, tell me so. Second question, maybe a more difficult one, I wonder if such a feature would be a popular one, or perhaps, something extremely outside of the way that we would want our repo's to be maintained? Maybe FreeBSD doesn't want to allow folks to have their own repos? I think that this ability, to make sure that your home repo is correct, is missing now for svn, I need to know if this is right, and that if the ability suddenly showed up, would that be a Good Thing or a Bad Thing? Whatever, it seems like a very fun thing to write, I hope it's not already written. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAknY7CAACgkQz62J6PPcoOk7NACfZ5pnVZcdOSFj/MKYOGe+PtUy BjYAn2sjL9AURZXf/hFXN08hXUuZtCp1 =05rB -----END PGP SIGNATURE----- From tinderbox at freebsd.org Sun Apr 5 11:16:30 2009 From: tinderbox at freebsd.org (FreeBSD Tinderbox) Date: Sun Apr 5 11:16:37 2009 Subject: [head tinderbox] failure on arm/arm Message-ID: <20090405181626.35E867302F@freebsd-current.sentex.ca> TB --- 2009-04-05 17:20:00 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2009-04-05 17:20:00 - starting HEAD tinderbox run for arm/arm TB --- 2009-04-05 17:20:00 - cleaning the object tree TB --- 2009-04-05 17:20:41 - cvsupping the source tree TB --- 2009-04-05 17:20:41 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/arm/arm/supfile TB --- 2009-04-05 17:20:49 - building world TB --- 2009-04-05 17:20:49 - MAKEOBJDIRPREFIX=/obj TB --- 2009-04-05 17:20:49 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-04-05 17:20:49 - TARGET=arm TB --- 2009-04-05 17:20:49 - TARGET_ARCH=arm TB --- 2009-04-05 17:20:49 - TZ=UTC TB --- 2009-04-05 17:20:49 - __MAKE_CONF=/dev/null TB --- 2009-04-05 17:20:49 - cd /src TB --- 2009-04-05 17:20:49 - /usr/bin/make -B buildworld >>> World build started on Sun Apr 5 17:20:51 UTC 2009 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything [...] cc1: warnings being treated as errors /src/sbin/routed/if.c: In function 'rt_xaddrs': /src/sbin/routed/if.c:631: warning: cast increases required alignment of target type /src/sbin/routed/if.c: In function 'ifinit': /src/sbin/routed/if.c:705: warning: cast increases required alignment of target type /src/sbin/routed/if.c:706: warning: cast increases required alignment of target type /src/sbin/routed/if.c:710: warning: cast increases required alignment of target type /src/sbin/routed/if.c:954: warning: format '%ld' expects type 'long int', but argument 3 has type 'time_t' *** Error code 1 Stop in /src/sbin/routed. *** Error code 1 Stop in /obj/arm/src/rescue/rescue. *** Error code 1 Stop in /src/rescue/rescue. *** Error code 1 Stop in /src/rescue. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-04-05 18:16:26 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-04-05 18:16:26 - ERROR: failed to build world TB --- 2009-04-05 18:16:26 - 2568.48 user 323.70 system 3385.48 real http://tinderbox.des.no/tinderbox-head-HEAD-arm-arm.full From tinderbox at freebsd.org Sun Apr 5 11:30:41 2009 From: tinderbox at freebsd.org (FreeBSD Tinderbox) Date: Sun Apr 5 11:30:54 2009 Subject: [head tinderbox] failure on amd64/amd64 Message-ID: <20090405183036.138117302F@freebsd-current.sentex.ca> TB --- 2009-04-05 17:20:00 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2009-04-05 17:20:00 - starting HEAD tinderbox run for amd64/amd64 TB --- 2009-04-05 17:20:00 - cleaning the object tree TB --- 2009-04-05 17:21:10 - cvsupping the source tree TB --- 2009-04-05 17:21:10 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/amd64/amd64/supfile TB --- 2009-04-05 17:21:17 - building world TB --- 2009-04-05 17:21:17 - MAKEOBJDIRPREFIX=/obj TB --- 2009-04-05 17:21:17 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-04-05 17:21:17 - TARGET=amd64 TB --- 2009-04-05 17:21:17 - TARGET_ARCH=amd64 TB --- 2009-04-05 17:21:17 - TZ=UTC TB --- 2009-04-05 17:21:17 - __MAKE_CONF=/dev/null TB --- 2009-04-05 17:21:17 - cd /src TB --- 2009-04-05 17:21:17 - /usr/bin/make -B buildworld >>> World build started on Sun Apr 5 17:21:20 UTC 2009 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything [...] rm -f .depend mkdep -f .depend -a -DRESCUE /src/sbin/routed/rtquery/rtquery.c echo rtquery: /obj/amd64/src/tmp/usr/lib/libc.a /obj/amd64/src/tmp/usr/lib/libmd.a >> .depend cc -O2 -pipe -DRESCUE -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wunused-parameter -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wno-pointer-sign -c /src/sbin/routed/if.c cc -O2 -pipe -DRESCUE -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wunused-parameter -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wno-pointer-sign -c /src/sbin/routed/input.c cc1: warnings being treated as errors /src/sbin/routed/input.c: In function 'ck_passwd': /src/sbin/routed/input.c:984: warning: format '%#x' expects type 'unsigned int', but argument 5 has type 'long unsigned int' *** Error code 1 Stop in /src/sbin/routed. *** Error code 1 Stop in /obj/amd64/src/rescue/rescue. *** Error code 1 Stop in /src/rescue/rescue. *** Error code 1 Stop in /src/rescue. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-04-05 18:30:35 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-04-05 18:30:35 - ERROR: failed to build world TB --- 2009-04-05 18:30:35 - 3245.27 user 338.72 system 4235.45 real http://tinderbox.des.no/tinderbox-head-HEAD-amd64-amd64.full From rnoland at FreeBSD.org Sun Apr 5 11:42:24 2009 From: rnoland at FreeBSD.org (Robert Noland) Date: Sun Apr 5 11:42:30 2009 Subject: xorg loops In-Reply-To: <49D8D03B.8090302@arcor.de> References: <49D8D03B.8090302@arcor.de> Message-ID: <1238956838.1829.7.camel@balrog.2hip.net> On Sun, 2009-04-05 at 17:37 +0200, Manfred Lotz wrote: > Hi all, > Using 8 current from time to time I have an xorg problem. > > Getting millions of those messages > > (II) Mouse autoprobe: Changing protocol to ExplorerPS/2 > (II) Mouse autoprobe: Changing protocol to ImPS/2 > > the system is unusable. No response from keyboard or mouse any more. > > > > Any idea, what I can do to prevent this from happining? Use moused... I've seen this with some of my mice lately... I don't know the input driver stuff well enough to really chase it down without wasting a lot of time that is better spent on other things. My experience was that it either happened right after X startup, or it would be fine. I think maybe the bug is in the psm driver in the kernel, but I'm not certain. robert. > > -- Robert Noland FreeBSD -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 196 bytes Desc: This is a digitally signed message part Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20090405/01f1daf9/attachment.pgp From rnoland at FreeBSD.org Sun Apr 5 11:51:51 2009 From: rnoland at FreeBSD.org (Robert Noland) Date: Sun Apr 5 11:51:59 2009 Subject: xorg loops In-Reply-To: <3a142e750904050919l1388b559t9bbd751546e239e7@mail.gmail.com> References: <49D8D03B.8090302@arcor.de> <3a142e750904050919l1388b559t9bbd751546e239e7@mail.gmail.com> Message-ID: <1238957462.1829.8.camel@balrog.2hip.net> On Sun, 2009-04-05 at 18:19 +0200, Paul B. Mahol wrote: > On 4/5/09, Manfred Lotz wrote: > > Hi all, > > Using 8 current from time to time I have an xorg problem. > > > > Getting millions of those messages > > > > (II) Mouse autoprobe: Changing protocol to ExplorerPS/2 > > (II) Mouse autoprobe: Changing protocol to ImPS/2 > > > > the system is unusable. No response from keyboard or mouse any more. > > > > > > > > Any idea, what I can do to prevent this from happining? > > Disable hal if it is enabled? No, the issue isn't hal... robert. -- Robert Noland FreeBSD -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 196 bytes Desc: This is a digitally signed message part Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20090405/40227dd2/attachment.pgp From peterwang at vip.qq.com Sun Apr 5 12:00:25 2009 From: peterwang at vip.qq.com (Peter Wang) Date: Sun Apr 5 12:00:34 2009 Subject: How to find out which ports contains a specified command. Message-ID: for example, after i installed pfsense, which is based on freebsd release 7.1, i found adduser command is missing. so how to find out which ports contains `adduser' command? thanks for your replies. -peter From manfred.lotz at arcor.de Sun Apr 5 12:15:50 2009 From: manfred.lotz at arcor.de (Manfred Lotz) Date: Sun Apr 5 12:15:57 2009 Subject: xorg loops In-Reply-To: <1238957462.1829.8.camel@balrog.2hip.net> References: <49D8D03B.8090302@arcor.de> <3a142e750904050919l1388b559t9bbd751546e239e7@mail.gmail.com> <1238957462.1829.8.camel@balrog.2hip.net> Message-ID: <49D90363.6010602@arcor.de> Robert Noland wrote: > On Sun, 2009-04-05 at 18:19 +0200, Paul B. Mahol wrote: > >> On 4/5/09, Manfred Lotz wrote: >> >>> Hi all, >>> Using 8 current from time to time I have an xorg problem. >>> >>> Getting millions of those messages >>> >>> (II) Mouse autoprobe: Changing protocol to ExplorerPS/2 >>> (II) Mouse autoprobe: Changing protocol to ImPS/2 >>> >>> the system is unusable. No response from keyboard or mouse any more. >>> >>> >>> >>> Any idea, what I can do to prevent this from happining? >>> >> Disable hal if it is enabled? >> > > No, the issue isn't hal... > > robert. > > But disabling HAL gave me the possibility to use moused again (as in older xorg times) which you recommended in the other reply. Anyway, I don't like the idea to have hal and dbus active as a prerequisite for running xorg. I just didn't know that I could get rid of hal. -- Manfred From kostikbel at gmail.com Sun Apr 5 12:28:32 2009 From: kostikbel at gmail.com (Kostik Belousov) Date: Sun Apr 5 12:28:39 2009 Subject: [head tinderbox] failure on ia64/ia64 In-Reply-To: <1238959517.4546.1.camel@localhost.localdomain> References: <20090401164947.873CE7302F@freebsd-current.sentex.ca> <20090401165845.GU31897@deviant.kiev.zoral.com.ua> <1238959517.4546.1.camel@localhost.localdomain> Message-ID: <20090405192824.GT31897@deviant.kiev.zoral.com.ua> On Sun, Apr 05, 2009 at 12:25:17PM -0700, Sean Bruno wrote: > On Wed, 2009-04-01 at 19:58 +0300, Kostik Belousov wrote: > > On Wed, Apr 01, 2009 at 11:49:47AM -0500, FreeBSD Tinderbox wrote: > > > TB --- 2009-04-01 14:36:51 - tinderbox 2.6 running on freebsd-current.sentex.ca > > > TB --- 2009-04-01 14:36:51 - starting HEAD tinderbox run for ia64/ia64 > > > TB --- 2009-04-01 14:36:51 - cleaning the object tree > > > TB --- 2009-04-01 14:37:32 - cvsupping the source tree > > > TB --- 2009-04-01 14:37:32 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/ia64/ia64/supfile > > > TB --- 2009-04-01 14:37:40 - building world > > > TB --- 2009-04-01 14:37:40 - MAKEOBJDIRPREFIX=/obj > > > TB --- 2009-04-01 14:37:40 - PATH=/usr/bin:/usr/sbin:/bin:/sbin > > > TB --- 2009-04-01 14:37:40 - TARGET=ia64 > > > TB --- 2009-04-01 14:37:40 - TARGET_ARCH=ia64 > > > TB --- 2009-04-01 14:37:40 - TZ=UTC > > > TB --- 2009-04-01 14:37:40 - __MAKE_CONF=/dev/null > > > TB --- 2009-04-01 14:37:40 - cd /src > > > TB --- 2009-04-01 14:37:40 - /usr/bin/make -B buildworld > > > >>> World build started on Wed Apr 1 14:37:42 UTC 2009 > > > >>> Rebuilding the temporary build tree > > > >>> stage 1.1: legacy release compatibility shims > > > >>> stage 1.2: bootstrap tools > > > >>> stage 2.1: cleaning up the object tree > > > >>> stage 2.2: rebuilding the object tree > > > >>> stage 2.3: build tools > > > >>> stage 3: cross tools > > > >>> stage 4.1: building includes > > > >>> stage 4.2: building libraries > > > >>> stage 4.3: make dependencies > > > >>> stage 4.4: building everything > > > >>> World build completed on Wed Apr 1 16:27:40 UTC 2009 > > > TB --- 2009-04-01 16:27:40 - generating LINT kernel config > > > TB --- 2009-04-01 16:27:40 - cd /src/sys/ia64/conf > > > TB --- 2009-04-01 16:27:40 - /usr/bin/make -B LINT > > > TB --- 2009-04-01 16:27:40 - building LINT kernel > > > TB --- 2009-04-01 16:27:40 - MAKEOBJDIRPREFIX=/obj > > > TB --- 2009-04-01 16:27:40 - PATH=/usr/bin:/usr/sbin:/bin:/sbin > > > TB --- 2009-04-01 16:27:40 - TARGET=ia64 > > > TB --- 2009-04-01 16:27:40 - TARGET_ARCH=ia64 > > > TB --- 2009-04-01 16:27:40 - TZ=UTC > > > TB --- 2009-04-01 16:27:40 - __MAKE_CONF=/dev/null > > > TB --- 2009-04-01 16:27:40 - cd /src > > > TB --- 2009-04-01 16:27:40 - /usr/bin/make -B buildkernel KERNCONF=LINT > > > >>> Kernel build for LINT started on Wed Apr 1 16:27:40 UTC 2009 > > > >>> stage 1: configuring the kernel > > > >>> stage 2.1: cleaning up the object tree > > > >>> stage 2.2: rebuilding the object tree > > > >>> stage 2.3: build tools > > > >>> stage 3.1: making dependencies > > > >>> stage 3.2: building everything > > > [...] > > > cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ia64/libuwx/src -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -fpic -ffreestanding -Werror vnode_if.c > > > :> hack.c > > > cc -shared -nostdlib hack.c -o hack.So > > > rm -f hack.c > > > MAKE=/usr/bin/make sh /src/sys/conf/newvers.sh LINT > > > cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ia64/libuwx/src -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -fpic -ffreestanding -Werror vers.c > > > linking kernel > > > freebsd32_sysent.o(.data.rel+0x19d0): undefined reference to `freebsd32_sysarch' > > > *** Error code 1 > > > > > > Stop in /obj/ia64/src/sys/LINT. > > > *** Error code 1 > > > > > > Stop in /src. > > > *** Error code 1 > > > > > > Stop in /src. > > > TB --- 2009-04-01 16:49:45 - WARNING: /usr/bin/make returned exit code 1 > > > TB --- 2009-04-01 16:49:45 - ERROR: failed to build lint kernel > > > TB --- 2009-04-01 16:49:45 - 6522.28 user 458.22 system 7973.66 real > > > > This is mine. I will fix it shortly. > > Kostik: > > This is also affecting my x86_64 builds. Thanks for looking at it. Huh ? There are two architectures that use compat32 bits. They are amd64 and ia64. Build for amd64 arch was not broken by these commits. It was my overlook to not provide bits for ia64 after compat/freebsd32/syscalls.master referenced new symbol, namely freebsd32_sysarch. So, if you have some issues, please report them in the details. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20090405/7713cd6c/attachment.pgp From rnoland at FreeBSD.org Sun Apr 5 12:32:56 2009 From: rnoland at FreeBSD.org (Robert Noland) Date: Sun Apr 5 12:33:03 2009 Subject: xorg loops In-Reply-To: <49D90363.6010602@arcor.de> References: <49D8D03B.8090302@arcor.de> <3a142e750904050919l1388b559t9bbd751546e239e7@mail.gmail.com> <1238957462.1829.8.camel@balrog.2hip.net> <49D90363.6010602@arcor.de> Message-ID: <1238959921.1829.10.camel@balrog.2hip.net> On Sun, 2009-04-05 at 21:15 +0200, Manfred Lotz wrote: > Robert Noland wrote: > > On Sun, 2009-04-05 at 18:19 +0200, Paul B. Mahol wrote: > > > >> On 4/5/09, Manfred Lotz wrote: > >> > >>> Hi all, > >>> Using 8 current from time to time I have an xorg problem. > >>> > >>> Getting millions of those messages > >>> > >>> (II) Mouse autoprobe: Changing protocol to ExplorerPS/2 > >>> (II) Mouse autoprobe: Changing protocol to ImPS/2 > >>> > >>> the system is unusable. No response from keyboard or mouse any more. > >>> > >>> > >>> > >>> Any idea, what I can do to prevent this from happining? > >>> > >> Disable hal if it is enabled? > >> > > > > No, the issue isn't hal... > > > > robert. > > > > > But disabling HAL gave me the possibility to use moused again (as in > older xorg times) which you recommended in the other reply. > > Anyway, I don't like the idea to have hal and dbus active as a > prerequisite for running xorg. I just didn't know that I could get rid > of hal. hald should work fine with moused now. robert. > > -- Robert Noland FreeBSD -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 196 bytes Desc: This is a digitally signed message part Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20090405/3b2b427b/attachment.pgp From kostikbel at gmail.com Sun Apr 5 12:37:17 2009 From: kostikbel at gmail.com (Kostik Belousov) Date: Sun Apr 5 12:37:26 2009 Subject: [head tinderbox] failure on ia64/ia64 In-Reply-To: <1238959919.4546.3.camel@localhost.localdomain> References: <20090401164947.873CE7302F@freebsd-current.sentex.ca> <20090401165845.GU31897@deviant.kiev.zoral.com.ua> <1238959517.4546.1.camel@localhost.localdomain> <20090405192824.GT31897@deviant.kiev.zoral.com.ua> <1238959919.4546.3.camel@localhost.localdomain> Message-ID: <20090405193709.GU31897@deviant.kiev.zoral.com.ua> On Sun, Apr 05, 2009 at 12:31:59PM -0700, Sean Bruno wrote: > > > > Kostik: > > > > > > This is also affecting my x86_64 builds. Thanks for looking at it. > > > > Huh ? There are two architectures that use compat32 bits. They > > are amd64 and ia64. Build for amd64 arch was not broken by these > > commits. It was my overlook to not provide bits for ia64 after > > compat/freebsd32/syscalls.master referenced new symbol, namely > > freebsd32_sysarch. > > > > So, if you have some issues, please report them in the details. > > I just updated my -current and am getting the following error on AMD64: > > [sean@bsd64 ~/bsd/head/sys/amd64/compile/GENERIC]$ make > linking kernel.debug > freebsd32_sysent.o(.data+0x19d0): undefined reference to > `freebsd32_sysarch' > *** Error code 1 > > Stop in /usr/home/sean/bsd/head/sys/amd64/compile/GENERIC. > > > Should I have to do anyting else? My guess is that you did not (re)configured your kernel after update. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20090405/363cb6d9/attachment.pgp From sean.bruno at dsl-only.net Sun Apr 5 12:38:42 2009 From: sean.bruno at dsl-only.net (Sean Bruno) Date: Sun Apr 5 12:38:54 2009 Subject: [head tinderbox] failure on ia64/ia64 In-Reply-To: <20090405192824.GT31897@deviant.kiev.zoral.com.ua> References: <20090401164947.873CE7302F@freebsd-current.sentex.ca> <20090401165845.GU31897@deviant.kiev.zoral.com.ua> <1238959517.4546.1.camel@localhost.localdomain> <20090405192824.GT31897@deviant.kiev.zoral.com.ua> Message-ID: <1238959919.4546.3.camel@localhost.localdomain> > > Kostik: > > > > This is also affecting my x86_64 builds. Thanks for looking at it. > > Huh ? There are two architectures that use compat32 bits. They > are amd64 and ia64. Build for amd64 arch was not broken by these > commits. It was my overlook to not provide bits for ia64 after > compat/freebsd32/syscalls.master referenced new symbol, namely > freebsd32_sysarch. > > So, if you have some issues, please report them in the details. I just updated my -current and am getting the following error on AMD64: [sean@bsd64 ~/bsd/head/sys/amd64/compile/GENERIC]$ make linking kernel.debug freebsd32_sysent.o(.data+0x19d0): undefined reference to `freebsd32_sysarch' *** Error code 1 Stop in /usr/home/sean/bsd/head/sys/amd64/compile/GENERIC. Should I have to do anyting else? Sean From sean.bruno at dsl-only.net Sun Apr 5 12:46:14 2009 From: sean.bruno at dsl-only.net (Sean Bruno) Date: Sun Apr 5 12:46:21 2009 Subject: [head tinderbox] failure on ia64/ia64 In-Reply-To: <20090405193709.GU31897@deviant.kiev.zoral.com.ua> References: <20090401164947.873CE7302F@freebsd-current.sentex.ca> <20090401165845.GU31897@deviant.kiev.zoral.com.ua> <1238959517.4546.1.camel@localhost.localdomain> <20090405192824.GT31897@deviant.kiev.zoral.com.ua> <1238959919.4546.3.camel@localhost.localdomain> <20090405193709.GU31897@deviant.kiev.zoral.com.ua> Message-ID: <1238960770.4546.4.camel@localhost.localdomain> On Sun, 2009-04-05 at 22:37 +0300, Kostik Belousov wrote: > On Sun, Apr 05, 2009 at 12:31:59PM -0700, Sean Bruno wrote: > > > > > > Kostik: > > > > > > > > This is also affecting my x86_64 builds. Thanks for looking at it. > > > > > > Huh ? There are two architectures that use compat32 bits. They > > > are amd64 and ia64. Build for amd64 arch was not broken by these > > > commits. It was my overlook to not provide bits for ia64 after > > > compat/freebsd32/syscalls.master referenced new symbol, namely > > > freebsd32_sysarch. > > > > > > So, if you have some issues, please report them in the details. > > > > I just updated my -current and am getting the following error on AMD64: > > > > [sean@bsd64 ~/bsd/head/sys/amd64/compile/GENERIC]$ make > > linking kernel.debug > > freebsd32_sysent.o(.data+0x19d0): undefined reference to > > `freebsd32_sysarch' > > *** Error code 1 > > > > Stop in /usr/home/sean/bsd/head/sys/amd64/compile/GENERIC. > > > > > > Should I have to do anyting else? > > My guess is that you did not (re)configured your kernel after update. Huh ... definitely my fault. I had restarted a full build after my last message and it compiled just fine. Forgive the noise. Sean From sean.bruno at dsl-only.net Sun Apr 5 12:51:59 2009 From: sean.bruno at dsl-only.net (Sean Bruno) Date: Sun Apr 5 12:52:05 2009 Subject: [head tinderbox] failure on ia64/ia64 In-Reply-To: <20090401165845.GU31897@deviant.kiev.zoral.com.ua> References: <20090401164947.873CE7302F@freebsd-current.sentex.ca> <20090401165845.GU31897@deviant.kiev.zoral.com.ua> Message-ID: <1238959517.4546.1.camel@localhost.localdomain> On Wed, 2009-04-01 at 19:58 +0300, Kostik Belousov wrote: > On Wed, Apr 01, 2009 at 11:49:47AM -0500, FreeBSD Tinderbox wrote: > > TB --- 2009-04-01 14:36:51 - tinderbox 2.6 running on freebsd-current.sentex.ca > > TB --- 2009-04-01 14:36:51 - starting HEAD tinderbox run for ia64/ia64 > > TB --- 2009-04-01 14:36:51 - cleaning the object tree > > TB --- 2009-04-01 14:37:32 - cvsupping the source tree > > TB --- 2009-04-01 14:37:32 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/ia64/ia64/supfile > > TB --- 2009-04-01 14:37:40 - building world > > TB --- 2009-04-01 14:37:40 - MAKEOBJDIRPREFIX=/obj > > TB --- 2009-04-01 14:37:40 - PATH=/usr/bin:/usr/sbin:/bin:/sbin > > TB --- 2009-04-01 14:37:40 - TARGET=ia64 > > TB --- 2009-04-01 14:37:40 - TARGET_ARCH=ia64 > > TB --- 2009-04-01 14:37:40 - TZ=UTC > > TB --- 2009-04-01 14:37:40 - __MAKE_CONF=/dev/null > > TB --- 2009-04-01 14:37:40 - cd /src > > TB --- 2009-04-01 14:37:40 - /usr/bin/make -B buildworld > > >>> World build started on Wed Apr 1 14:37:42 UTC 2009 > > >>> Rebuilding the temporary build tree > > >>> stage 1.1: legacy release compatibility shims > > >>> stage 1.2: bootstrap tools > > >>> stage 2.1: cleaning up the object tree > > >>> stage 2.2: rebuilding the object tree > > >>> stage 2.3: build tools > > >>> stage 3: cross tools > > >>> stage 4.1: building includes > > >>> stage 4.2: building libraries > > >>> stage 4.3: make dependencies > > >>> stage 4.4: building everything > > >>> World build completed on Wed Apr 1 16:27:40 UTC 2009 > > TB --- 2009-04-01 16:27:40 - generating LINT kernel config > > TB --- 2009-04-01 16:27:40 - cd /src/sys/ia64/conf > > TB --- 2009-04-01 16:27:40 - /usr/bin/make -B LINT > > TB --- 2009-04-01 16:27:40 - building LINT kernel > > TB --- 2009-04-01 16:27:40 - MAKEOBJDIRPREFIX=/obj > > TB --- 2009-04-01 16:27:40 - PATH=/usr/bin:/usr/sbin:/bin:/sbin > > TB --- 2009-04-01 16:27:40 - TARGET=ia64 > > TB --- 2009-04-01 16:27:40 - TARGET_ARCH=ia64 > > TB --- 2009-04-01 16:27:40 - TZ=UTC > > TB --- 2009-04-01 16:27:40 - __MAKE_CONF=/dev/null > > TB --- 2009-04-01 16:27:40 - cd /src > > TB --- 2009-04-01 16:27:40 - /usr/bin/make -B buildkernel KERNCONF=LINT > > >>> Kernel build for LINT started on Wed Apr 1 16:27:40 UTC 2009 > > >>> stage 1: configuring the kernel > > >>> stage 2.1: cleaning up the object tree > > >>> stage 2.2: rebuilding the object tree > > >>> stage 2.3: build tools > > >>> stage 3.1: making dependencies > > >>> stage 3.2: building everything > > [...] > > cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ia64/libuwx/src -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -fpic -ffreestanding -Werror vnode_if.c > > :> hack.c > > cc -shared -nostdlib hack.c -o hack.So > > rm -f hack.c > > MAKE=/usr/bin/make sh /src/sys/conf/newvers.sh LINT > > cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ia64/libuwx/src -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -fpic -ffreestanding -Werror vers.c > > linking kernel > > freebsd32_sysent.o(.data.rel+0x19d0): undefined reference to `freebsd32_sysarch' > > *** Error code 1 > > > > Stop in /obj/ia64/src/sys/LINT. > > *** Error code 1 > > > > Stop in /src. > > *** Error code 1 > > > > Stop in /src. > > TB --- 2009-04-01 16:49:45 - WARNING: /usr/bin/make returned exit code 1 > > TB --- 2009-04-01 16:49:45 - ERROR: failed to build lint kernel > > TB --- 2009-04-01 16:49:45 - 6522.28 user 458.22 system 7973.66 real > > This is mine. I will fix it shortly. Kostik: This is also affecting my x86_64 builds. Thanks for looking at it. Sean From brd at FreeBSD.org Sun Apr 5 13:23:52 2009 From: brd at FreeBSD.org (Brad Davis) Date: Sun Apr 5 13:24:04 2009 Subject: FreeBSD Status Reports due April 20th, 2009 Message-ID: <20090405195109.GB25817@valentine.liquidneon.com> Hi Everyone, We would like to remind everybody who has exciting news to share to write a report about their project. This is a good way to improve exposure of your work, receive feedback and help. We are looking forward to your reports. As always you can either use the template or the CGI generator and mail the output to monthly@ by Wednesday April 20th, 2009. http://www.freebsd.org/news/status/ http://www.freebsd.org/cgi/monthly.cgi http://www.freebsd.org/news/status/report-sample.xml Regards, Brad Davis From njm at njm.me.uk Sun Apr 5 13:33:04 2009 From: njm at njm.me.uk (N.J. Mann) Date: Sun Apr 5 13:33:11 2009 Subject: FWD: Re: How to find out which ports contains a specified command. Message-ID: <20090405200614.GB5095@titania.njm.me.uk> [For some reason this did not get sent to the list originally, so for the archives...] In message , Peter Wang (peterwang@vip.qq.com) wrote: > > for example, after i installed pfsense, which is based on freebsd > release 7.1, i found adduser command is missing. > > so how to find out which ports contains `adduser' command? > thanks for your replies. % uname -sr FreeBSD 7.2-PRERELEASE % whereis adduser adduser: /usr/sbin/adduser /usr/share/man/en.ISO8859-15/man8/adduser.8 /usr/src/usr.sbin/adduser So, it is part of the base system. This can be confirmed by searching the on-line manual, i.e. http://www.freebsd.org/cgi/man.cgi?query=adduser&apropos=0&sektion=0&manpath=FreeBSD+7.1-RELEASE&format=html Cheers, Nick. PS I think you should have asked this on questions@. -- From scf at FreeBSD.org Sun Apr 5 13:39:43 2009 From: scf at FreeBSD.org (Sean C. Farley) Date: Sun Apr 5 13:39:54 2009 Subject: xorg loops In-Reply-To: <1238956838.1829.7.camel@balrog.2hip.net> References: <49D8D03B.8090302@arcor.de> <1238956838.1829.7.camel@balrog.2hip.net> Message-ID: On Sun, 5 Apr 2009, Robert Noland wrote: > On Sun, 2009-04-05 at 17:37 +0200, Manfred Lotz wrote: >> Hi all, >> Using 8 current from time to time I have an xorg problem. >> >> Getting millions of those messages >> >> (II) Mouse autoprobe: Changing protocol to ExplorerPS/2 >> (II) Mouse autoprobe: Changing protocol to ImPS/2 >> >> the system is unusable. No response from keyboard or mouse any more. >> >> Any idea, what I can do to prevent this from happining? > > Use moused... I've seen this with some of my mice lately... I don't > know the input driver stuff well enough to really chase it down > without wasting a lot of time that is better spent on other things. > My experience was that it either happened right after X startup, or it > would be fine. I think maybe the bug is in the psm driver in the > kernel, but I'm not certain. For another point of interest, after the xserver (and xf86-input-mouse) updates to 1.6, my laptop's GlidePointPS/2 is no longer detected as such. It uses vanilla PS/2 for it. I do not use hal nor moused. This is with RELENG_7, so it is not just CURRENT with the problem. Sean -- scf@FreeBSD.org From tinderbox at freebsd.org Sun Apr 5 14:40:47 2009 From: tinderbox at freebsd.org (FreeBSD Tinderbox) Date: Sun Apr 5 14:40:53 2009 Subject: [head tinderbox] failure on mips/mips Message-ID: <20090405214043.6C9B37302F@freebsd-current.sentex.ca> TB --- 2009-04-05 20:43:54 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2009-04-05 20:43:54 - starting HEAD tinderbox run for mips/mips TB --- 2009-04-05 20:43:54 - cleaning the object tree TB --- 2009-04-05 20:44:17 - cvsupping the source tree TB --- 2009-04-05 20:44:17 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/mips/mips/supfile TB --- 2009-04-05 20:44:26 - building world TB --- 2009-04-05 20:44:26 - MAKEOBJDIRPREFIX=/obj TB --- 2009-04-05 20:44:26 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-04-05 20:44:26 - TARGET=mips TB --- 2009-04-05 20:44:26 - TARGET_ARCH=mips TB --- 2009-04-05 20:44:26 - TZ=UTC TB --- 2009-04-05 20:44:26 - __MAKE_CONF=/dev/null TB --- 2009-04-05 20:44:26 - cd /src TB --- 2009-04-05 20:44:26 - /usr/bin/make -B buildworld >>> World build started on Sun Apr 5 20:44:27 UTC 2009 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything [...] /src/sbin/routed/if.c:846: warning: cast increases required alignment of target type /src/sbin/routed/if.c:846: warning: cast increases required alignment of target type /src/sbin/routed/if.c:846: warning: cast increases required alignment of target type /src/sbin/routed/if.c:846: warning: cast increases required alignment of target type /src/sbin/routed/if.c:846: warning: cast increases required alignment of target type /src/sbin/routed/if.c:846: warning: cast increases required alignment of target type /src/sbin/routed/if.c:865: warning: cast increases required alignment of target type /src/sbin/routed/if.c:954: warning: format '%ld' expects type 'long int', but argument 3 has type 'time_t' *** Error code 1 Stop in /src/sbin/routed. *** Error code 1 Stop in /src/sbin. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-04-05 21:40:43 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-04-05 21:40:43 - ERROR: failed to build world TB --- 2009-04-05 21:40:43 - 2619.25 user 310.66 system 3408.98 real http://tinderbox.des.no/tinderbox-head-HEAD-mips-mips.full From tmclaugh at sdf.lonestar.org Sun Apr 5 14:41:35 2009 From: tmclaugh at sdf.lonestar.org (Tom McLaughlin) Date: Sun Apr 5 14:41:43 2009 Subject: problem with nss_ldap In-Reply-To: <49B69C36.3010307@sdf.lonestar.org> References: <49A69B74.1080201@sdf.lonestar.org> <49A97F2E.3030005@sdf.lonestar.org> <20090306213531.G60465@beagle.kn.op.dlr.de> <20090306211650.GD41617@deviant.kiev.zoral.com.ua> <20090306222433.GF41617@deviant.kiev.zoral.com.ua> <20090310114131.GD41617@deviant.kiev.zoral.com.ua> <70D16F57-F7E3-4CDA-BCD5-5D79B566510B@rabson.org> <49B69C36.3010307@sdf.lonestar.org> Message-ID: <49D92586.6030803@sdf.lonestar.org> Tom McLaughlin wrote, On 03/10/2009 12:58 PM: > Doug Rabson wrote: >> On 10 Mar 2009, at 11:41, Kostik Belousov wrote: >> >>> On Tue, Mar 10, 2009 at 10:38:51AM +0000, Doug Rabson wrote: >>>> On 6 Mar 2009, at 22:24, Kostik Belousov wrote: >>>> >>>>> On Fri, Mar 06, 2009 at 05:00:49PM -0500, tmclaugh@sdf.lonestar.org >>>>> wrote: >>>>>>> On Fri, Mar 06, 2009 at 09:39:31PM +0100, Hartmut Brandt wrote: >>>>>>>> Hi Tom, >>>>>>>> >>>>>>>> On Sat, 28 Feb 2009, Tom McLaughlin wrote: >>>>>>>> >>>>>>>> TM>Tom McLaughlin wrote: >>>>>>>> TM>> Harti Brandt wrote: >>>>>>>> TM>> > On Sun, 18 Jan 2009, Hartmut.Brandt@dlr.de wrote: > Okay, attached is a patch to nss_ldap. On -CURRENT I have changed the > CONFIGURE_ARG to use "--enable-configurable-krb5-ccname-gssapi" instead > of "--enable-configurable-krb5-ccname-env" which fixes Harti's initial > problem with apps like cron failing. It will also make nss_ldap link > against libgssapi and libgssapi_krb5. I still have one lingering issue > though at least things work. > > [tom@freebsd-8-amd64 tom]$ getent passwd tom > dlopen: /usr/lib/libgssapi_spnego.so.10: Undefined symbol > "GSS_C_NT_HOSTBASED_SERVICE" > tom:x:10001:10001:Tom McLaughlin:/home/tom:/bin/sh > Hey, just curious if there's anything that can be done about the one lingering issue I have above with: dlopen: /usr/lib/libgssapi_spnego.so.10: Undefined symbol "GSS_C_NT_HOSTBASED_SERVICE" Got back from vacation and happen to go through my -CURRENT box's mailbox and cron has flooded my inbox with emails because of this. Would be nice to make this go away. :) tom -- | tmclaugh at sdf.lonestar.org tmclaugh at FreeBSD.org | | FreeBSD http://www.FreeBSD.org | From tinderbox at freebsd.org Sun Apr 5 15:04:48 2009 From: tinderbox at freebsd.org (FreeBSD Tinderbox) Date: Sun Apr 5 15:05:00 2009 Subject: [head tinderbox] failure on ia64/ia64 Message-ID: <20090405220444.4032F7302F@freebsd-current.sentex.ca> TB --- 2009-04-05 20:40:14 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2009-04-05 20:40:14 - starting HEAD tinderbox run for ia64/ia64 TB --- 2009-04-05 20:40:14 - cleaning the object tree TB --- 2009-04-05 20:40:52 - cvsupping the source tree TB --- 2009-04-05 20:40:52 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/ia64/ia64/supfile TB --- 2009-04-05 20:41:07 - building world TB --- 2009-04-05 20:41:07 - MAKEOBJDIRPREFIX=/obj TB --- 2009-04-05 20:41:07 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-04-05 20:41:07 - TARGET=ia64 TB --- 2009-04-05 20:41:07 - TARGET_ARCH=ia64 TB --- 2009-04-05 20:41:07 - TZ=UTC TB --- 2009-04-05 20:41:07 - __MAKE_CONF=/dev/null TB --- 2009-04-05 20:41:07 - cd /src TB --- 2009-04-05 20:41:07 - /usr/bin/make -B buildworld >>> World build started on Sun Apr 5 20:41:09 UTC 2009 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything [...] /src/sbin/routed/if.c: In function 'ifinit': /src/sbin/routed/if.c:710: warning: cast increases required alignment of target type /src/sbin/routed/if.c:719: warning: cast increases required alignment of target type /src/sbin/routed/if.c:777: warning: cast increases required alignment of target type /src/sbin/routed/if.c:818: warning: cast increases required alignment of target type /src/sbin/routed/if.c:831: warning: cast increases required alignment of target type /src/sbin/routed/if.c:846: warning: cast increases required alignment of target type /src/sbin/routed/if.c:865: warning: cast increases required alignment of target type *** Error code 1 Stop in /src/sbin/routed. *** Error code 1 Stop in /obj/ia64/src/rescue/rescue. *** Error code 1 Stop in /src/rescue/rescue. *** Error code 1 Stop in /src/rescue. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-04-05 22:04:44 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-04-05 22:04:44 - ERROR: failed to build world TB --- 2009-04-05 22:04:44 - 4083.05 user 333.75 system 5069.86 real http://tinderbox.des.no/tinderbox-head-HEAD-ia64-ia64.full From rnoland at FreeBSD.org Sun Apr 5 15:19:06 2009 From: rnoland at FreeBSD.org (Robert Noland) Date: Sun Apr 5 15:19:12 2009 Subject: xorg loops In-Reply-To: References: <49D8D03B.8090302@arcor.de> <1238956838.1829.7.camel@balrog.2hip.net> Message-ID: <1238969895.1829.14.camel@balrog.2hip.net> On Sun, 2009-04-05 at 15:39 -0500, Sean C. Farley wrote: > On Sun, 5 Apr 2009, Robert Noland wrote: > > > On Sun, 2009-04-05 at 17:37 +0200, Manfred Lotz wrote: > >> Hi all, > >> Using 8 current from time to time I have an xorg problem. > >> > >> Getting millions of those messages > >> > >> (II) Mouse autoprobe: Changing protocol to ExplorerPS/2 > >> (II) Mouse autoprobe: Changing protocol to ImPS/2 > >> > >> the system is unusable. No response from keyboard or mouse any more. > >> > >> Any idea, what I can do to prevent this from happining? > > > > Use moused... I've seen this with some of my mice lately... I don't > > know the input driver stuff well enough to really chase it down > > without wasting a lot of time that is better spent on other things. > > My experience was that it either happened right after X startup, or it > > would be fine. I think maybe the bug is in the psm driver in the > > kernel, but I'm not certain. > > For another point of interest, after the xserver (and xf86-input-mouse) > updates to 1.6, my laptop's GlidePointPS/2 is no longer detected as > such. It uses vanilla PS/2 for it. I do not use hal nor moused. This > is with RELENG_7, so it is not just CURRENT with the problem. There were no changes to the mouse driver. Only difference is that the os-support routines now only live in the mouse driver. So that is where to go looking for trouble. robert. > Sean -- Robert Noland FreeBSD -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 196 bytes Desc: This is a digitally signed message part Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20090405/22540fb6/attachment.pgp From tinderbox at freebsd.org Sun Apr 5 16:10:35 2009 From: tinderbox at freebsd.org (FreeBSD Tinderbox) Date: Sun Apr 5 16:10:42 2009 Subject: [head tinderbox] failure on sparc64/sparc64 Message-ID: <20090405231030.550AC7302F@freebsd-current.sentex.ca> TB --- 2009-04-05 22:04:44 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2009-04-05 22:04:44 - starting HEAD tinderbox run for sparc64/sparc64 TB --- 2009-04-05 22:04:44 - cleaning the object tree TB --- 2009-04-05 22:05:17 - cvsupping the source tree TB --- 2009-04-05 22:05:17 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/sparc64/sparc64/supfile TB --- 2009-04-05 22:05:25 - building world TB --- 2009-04-05 22:05:25 - MAKEOBJDIRPREFIX=/obj TB --- 2009-04-05 22:05:25 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-04-05 22:05:25 - TARGET=sparc64 TB --- 2009-04-05 22:05:25 - TARGET_ARCH=sparc64 TB --- 2009-04-05 22:05:25 - TZ=UTC TB --- 2009-04-05 22:05:25 - __MAKE_CONF=/dev/null TB --- 2009-04-05 22:05:25 - cd /src TB --- 2009-04-05 22:05:25 - /usr/bin/make -B buildworld >>> World build started on Sun Apr 5 22:05:27 UTC 2009 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything [...] /src/sbin/routed/if.c: In function 'ifinit': /src/sbin/routed/if.c:710: warning: cast increases required alignment of target type /src/sbin/routed/if.c:719: warning: cast increases required alignment of target type /src/sbin/routed/if.c:777: warning: cast increases required alignment of target type /src/sbin/routed/if.c:818: warning: cast increases required alignment of target type /src/sbin/routed/if.c:831: warning: cast increases required alignment of target type /src/sbin/routed/if.c:846: warning: cast increases required alignment of target type /src/sbin/routed/if.c:865: warning: cast increases required alignment of target type *** Error code 1 Stop in /src/sbin/routed. *** Error code 1 Stop in /obj/sparc64/src/rescue/rescue. *** Error code 1 Stop in /src/rescue/rescue. *** Error code 1 Stop in /src/rescue. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-04-05 23:10:30 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-04-05 23:10:30 - ERROR: failed to build world TB --- 2009-04-05 23:10:30 - 3077.88 user 317.62 system 3945.73 real http://tinderbox.des.no/tinderbox-head-HEAD-sparc64-sparc64.full From tinderbox at freebsd.org Sun Apr 5 17:12:54 2009 From: tinderbox at freebsd.org (FreeBSD Tinderbox) Date: Sun Apr 5 17:13:12 2009 Subject: [head tinderbox] failure on sparc64/sun4v Message-ID: <20090406001251.1D8BE7302F@freebsd-current.sentex.ca> TB --- 2009-04-05 23:10:30 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2009-04-05 23:10:30 - starting HEAD tinderbox run for sparc64/sun4v TB --- 2009-04-05 23:10:30 - cleaning the object tree TB --- 2009-04-05 23:10:51 - cvsupping the source tree TB --- 2009-04-05 23:10:51 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/sparc64/sun4v/supfile TB --- 2009-04-05 23:11:01 - building world TB --- 2009-04-05 23:11:01 - MAKEOBJDIRPREFIX=/obj TB --- 2009-04-05 23:11:01 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-04-05 23:11:01 - TARGET=sun4v TB --- 2009-04-05 23:11:01 - TARGET_ARCH=sparc64 TB --- 2009-04-05 23:11:01 - TZ=UTC TB --- 2009-04-05 23:11:01 - __MAKE_CONF=/dev/null TB --- 2009-04-05 23:11:01 - cd /src TB --- 2009-04-05 23:11:01 - /usr/bin/make -B buildworld >>> World build started on Sun Apr 5 23:11:02 UTC 2009 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything [...] /src/sbin/routed/if.c: In function 'ifinit': /src/sbin/routed/if.c:710: warning: cast increases required alignment of target type /src/sbin/routed/if.c:719: warning: cast increases required alignment of target type /src/sbin/routed/if.c:777: warning: cast increases required alignment of target type /src/sbin/routed/if.c:818: warning: cast increases required alignment of target type /src/sbin/routed/if.c:831: warning: cast increases required alignment of target type /src/sbin/routed/if.c:846: warning: cast increases required alignment of target type /src/sbin/routed/if.c:865: warning: cast increases required alignment of target type *** Error code 1 Stop in /src/sbin/routed. *** Error code 1 Stop in /obj/sun4v/src/rescue/rescue. *** Error code 1 Stop in /src/rescue/rescue. *** Error code 1 Stop in /src/rescue. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-04-06 00:12:50 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-04-06 00:12:50 - ERROR: failed to build world TB --- 2009-04-06 00:12:50 - 3062.78 user 310.08 system 3740.57 real http://tinderbox.des.no/tinderbox-head-HEAD-sparc64-sun4v.full From villa.alberto at gmail.com Sun Apr 5 17:14:25 2009 From: villa.alberto at gmail.com (Alberto Villa) Date: Sun Apr 5 17:14:58 2009 Subject: How to find out which ports contains a specified command. In-Reply-To: <20090405200614.GB5095@titania.njm.me.uk> References: <20090405200614.GB5095@titania.njm.me.uk> Message-ID: On Sun, Apr 5, 2009 at 10:06 PM, N.J. Mann wrote: > adduser: /usr/sbin/adduser /usr/share/man/en.ISO8859-15/man8/adduser.8 /usr/src/usr.sbin/adduser > > So, it is part of the base system. ?This can be confirmed by searching > the on-line manual, i.e. anyway, if you're looking for other programs, i can't remember if there is any special way... i think i'd try something like: cd /usr/ports && grep -i "bin/$yourcommand" -f */*/pkg-plist -- Alberto Villa From scf at FreeBSD.org Sun Apr 5 17:53:10 2009 From: scf at FreeBSD.org (Sean C. Farley) Date: Sun Apr 5 17:53:17 2009 Subject: xorg loops In-Reply-To: <1238969895.1829.14.camel@balrog.2hip.net> References: <49D8D03B.8090302@arcor.de> <1238956838.1829.7.camel@balrog.2hip.net> <1238969895.1829.14.camel@balrog.2hip.net> Message-ID: On Sun, 5 Apr 2009, Robert Noland wrote: > On Sun, 2009-04-05 at 15:39 -0500, Sean C. Farley wrote: >> On Sun, 5 Apr 2009, Robert Noland wrote: >> >>> Use moused... I've seen this with some of my mice lately... I don't >>> know the input driver stuff well enough to really chase it down >>> without wasting a lot of time that is better spent on other things. >>> My experience was that it either happened right after X startup, or it >>> would be fine. I think maybe the bug is in the psm driver in the >>> kernel, but I'm not certain. >> >> For another point of interest, after the xserver (and xf86-input-mouse) >> updates to 1.6, my laptop's GlidePointPS/2 is no longer detected as >> such. It uses vanilla PS/2 for it. I do not use hal nor moused. This >> is with RELENG_7, so it is not just CURRENT with the problem. > > There were no changes to the mouse driver. Only difference is that the > os-support routines now only live in the mouse driver. So that is where > to go looking for trouble. > > robert. While the mouse driver is patched, I do not see where XPS2_SUPPORT is actually set anywhere in the build. Defining it allows the driver to detect my mouse. Actually, before the patch it would not even let me set it to GlidePointPS/2. Sean -- scf@FreeBSD.org From rnoland at FreeBSD.org Sun Apr 5 18:04:51 2009 From: rnoland at FreeBSD.org (Robert Noland) Date: Sun Apr 5 18:04:58 2009 Subject: xorg loops In-Reply-To: References: <49D8D03B.8090302@arcor.de> <1238956838.1829.7.camel@balrog.2hip.net> <1238969895.1829.14.camel@balrog.2hip.net> Message-ID: <1238979841.1829.20.camel@balrog.2hip.net> On Sun, 2009-04-05 at 19:53 -0500, Sean C. Farley wrote: > On Sun, 5 Apr 2009, Robert Noland wrote: > > > On Sun, 2009-04-05 at 15:39 -0500, Sean C. Farley wrote: > >> On Sun, 5 Apr 2009, Robert Noland wrote: > >> > >>> Use moused... I've seen this with some of my mice lately... I don't > >>> know the input driver stuff well enough to really chase it down > >>> without wasting a lot of time that is better spent on other things. > >>> My experience was that it either happened right after X startup, or it > >>> would be fine. I think maybe the bug is in the psm driver in the > >>> kernel, but I'm not certain. > >> > >> For another point of interest, after the xserver (and xf86-input-mouse) > >> updates to 1.6, my laptop's GlidePointPS/2 is no longer detected as > >> such. It uses vanilla PS/2 for it. I do not use hal nor moused. This > >> is with RELENG_7, so it is not just CURRENT with the problem. > > > > There were no changes to the mouse driver. Only difference is that the > > os-support routines now only live in the mouse driver. So that is where > > to go looking for trouble. > > > > robert. > > While the mouse driver is patched, I do not see where XPS2_SUPPORT is > actually set anywhere in the build. I remember messing with that after the last upgrade, when I was trying to deal with mice issues. jkim@ said something about it only being supported on more recent platforms. robert. > Defining it allows the driver to detect my mouse. Actually, before the > patch it would not even let me set it to GlidePointPS/2. > > Sean -- Robert Noland FreeBSD -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 196 bytes Desc: This is a digitally signed message part Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20090406/cd3c0ceb/attachment.pgp From keramida at ceid.upatras.gr Sun Apr 5 18:10:08 2009 From: keramida at ceid.upatras.gr (Giorgos Keramidas) Date: Sun Apr 5 18:10:16 2009 Subject: comparing svn and cvs somewhat In-Reply-To: <49D8EC20.70700@telenix.org> (Chuck Robey's message of "Sun, 05 Apr 2009 13:36:32 -0400") References: <49D8EC20.70700@telenix.org> Message-ID: <87d4bq4non.fsf@kobe.laptop> On Sun, 05 Apr 2009 13:36:32 -0400, Chuck Robey wrote: > I have gotten a local copy of the svn repo going on my home here, by > using svnsync, which seems (by what I've read and been told) to be the > right method. I'm wondering about a feature that is there for cvs, in > cvsup, but which seems to be missing in svnsync for svn. > > What I'm after is a much better way to maintain a local repo than what > I'm seeing now in maintaining my svn repo, with svnsync. The main > feature that I think I'm missing is the ability to be able to compare > files on a central server (something serving all FreeBSDers) to files > on everybody's personal repo, and to automatically update them if > there isn't a perfect comparison. I am not sure if it's any help but `svnadmin verify /local/path' seems to be doing half of the work you want. I am not sure if the Subversion wire-protocol supports remotely doing this, but maybe it's a feature the Subversion team would be interested to add to the core SCM system? It does sound useful, at least for FSFS-style repositories like ours :) From tinderbox at freebsd.org Sun Apr 5 18:16:15 2009 From: tinderbox at freebsd.org (FreeBSD Tinderbox) Date: Sun Apr 5 18:16:22 2009 Subject: [head tinderbox] failure on arm/arm Message-ID: <20090406011612.42FB67302F@freebsd-current.sentex.ca> TB --- 2009-04-06 00:20:00 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2009-04-06 00:20:00 - starting HEAD tinderbox run for arm/arm TB --- 2009-04-06 00:20:00 - cleaning the object tree TB --- 2009-04-06 00:20:39 - cvsupping the source tree TB --- 2009-04-06 00:20:39 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/arm/arm/supfile TB --- 2009-04-06 00:20:56 - building world TB --- 2009-04-06 00:20:56 - MAKEOBJDIRPREFIX=/obj TB --- 2009-04-06 00:20:56 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-04-06 00:20:56 - TARGET=arm TB --- 2009-04-06 00:20:56 - TARGET_ARCH=arm TB --- 2009-04-06 00:20:56 - TZ=UTC TB --- 2009-04-06 00:20:56 - __MAKE_CONF=/dev/null TB --- 2009-04-06 00:20:56 - cd /src TB --- 2009-04-06 00:20:56 - /usr/bin/make -B buildworld >>> World build started on Mon Apr 6 00:20:58 UTC 2009 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything [...] echo rtquery: /obj/arm/src/tmp/usr/lib/libc.a /obj/arm/src/tmp/usr/lib/libmd.a >> .depend cc -O -pipe -DRESCUE -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wunused-parameter -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wno-pointer-sign -c /src/sbin/routed/if.c cc1: warnings being treated as errors /src/sbin/routed/if.c: In function 'rt_xaddrs': /src/sbin/routed/if.c:631: warning: cast increases required alignment of target type /src/sbin/routed/if.c: In function 'ifinit': /src/sbin/routed/if.c:710: warning: cast increases required alignment of target type /src/sbin/routed/if.c:954: warning: format '%ld' expects type 'long int', but argument 3 has type 'time_t' *** Error code 1 Stop in /src/sbin/routed. *** Error code 1 Stop in /obj/arm/src/rescue/rescue. *** Error code 1 Stop in /src/rescue/rescue. *** Error code 1 Stop in /src/rescue. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-04-06 01:16:12 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-04-06 01:16:12 - ERROR: failed to build world TB --- 2009-04-06 01:16:12 - 2564.27 user 326.12 system 3371.60 real http://tinderbox.des.no/tinderbox-head-HEAD-arm-arm.full From avatar at mmlab.cse.yzu.edu.tw Sun Apr 5 18:33:02 2009 From: avatar at mmlab.cse.yzu.edu.tw (Tai-hwa Liang) Date: Sun Apr 5 18:33:09 2009 Subject: Removal of GEOM_BSD, GEOM_MBR, GEOM_PC98 and GEOM_SUNLABEL In-Reply-To: <42E3BB6C-16C7-4211-A4FD-A362383418E9@mac.com> References: <60084D1E-9F64-463A-A8E9-7A237D5C7661@mac.com> <0904011910169.29800@www.mmlab.cse.yzu.edu.tw> <0904020940371.36257@www.mmlab.cse.yzu.edu.tw> <4CCDEFD6-830E-4C8F-B7A2-B7878F8842BE@mac.com> <0904021314574.37737@www.mmlab.cse.yzu.edu.tw> <09040309313414.76643@www.mmlab.cse.yzu.edu.tw> <0904031327195.78401@www.mmlab.cse.yzu.edu.tw> <8583A3BA-2871-4DF4-9792-1031044A4A22@mac.com> <09040315161311.79260@www.mmlab.cse.yzu.edu.tw> <1DDB4728-7742-4265-999F-F1A0FC69F9E4@mac.com> <0904040858433.86299@www.mmlab.cse.yzu.edu.tw> <7AD352A2-BEDD-4DFD-896D-104E6376D887@mac.com> <09040411131618.87313@www.mmlab.cse.yzu.edu.tw> <09040423143118.91304@www.mmlab.cse.yzu.edu.tw> <42E3BB6C-16C7-4211-A4FD-A362383418E9@mac.com> Message-ID: <0904060920495.5188@www.mmlab.cse.yzu.edu.tw> On Sat, 4 Apr 2009, Marcel Moolenaar wrote: > > On Apr 4, 2009, at 8:16 AM, Tai-hwa Liang wrote: > >> I have to use ad0s7 after moving to GEOM_PART_{BSD,EBR,MBR}; otherwise, >> booting with with /dev/ad0s7a looks like: > >> Can't stat /dev/ad0s7a: No such file or directory > > It just hit me (doh!). The problem is that /dev/ad0s7 is a > compatibility symlink, which exists outside of the GEOM > graph. That is, it's a symlink that geom_dev creates and > it provides an alternate name to the same "entry point". > > In your case another GEOM (gpart for the BSD scheme) is > stacked onto the gpart GEOM for the EBR scheme) -- with > possibly other GEOMs in between. The provider for the 'a' > partition is named based on the underlying consumer, which > is based on the true name of the GEOM: "ad0s3+00103bf1a". > > There's no alias for the device node that corresponds to > this GEOM and based on some alias that was created by some > other geom_dev. This is simply not possible to without > messing things up pretty easily. > > In short: the solution of using a compatibility symlink is > flawed at best and useless in the worst case. Just found another breakage with compatibility symlink: # geli attach -k ~avatar/seprom.bin /dev/ad0s8 Enter passphrase: geli: Provider ad0s8 is invalid. # geli dump /dev/ad0s8 magic: GEOM::ELI version: 3 flags: 0x0 ealgo: AES-CBC keylen: 128 provsize: 48423707136 sectorsize: 4096 keys: 0x01 iterations: 48331 Salt: ..... Master Key: ..... MD5 hash: 38d02b9d0cae948d358e6bc2d570ee7d # Replacing /dev/ad0s8 with /dev/ad0s3+0017cda1 or using old GEOM_{MBR,BSD} solves the problem. > There's no software fix for it. I think we're left with a > simple choice: > 1) have EBR create the "old" names and tell the user to > reboot every time they make a change in FreeBSD and when > booting into FreeBSD after the EBR changed, boot into > single user mode to change /etc/fstab and *then* go into > multi-user mode, or > 2) stick with the new names and tell the user to make this > one-time adjustment during upgrades and that's it. > > If we choose 2, we can argue whether to keep the symlinks > or not. I'm sure there's a small group of people for which > it works, but I fear the majority of people still have > problems. > > Any thoughts? Given that the current symlink approach doesn't work well for me, I think both choices wouldn't make too much differences to me. Frankly, sticking with old GEOM_{MBR,BSD} probably introduces less POLA issues in my case. -- Thanks, Tai-hwa Liang From wxs at FreeBSD.org Sun Apr 5 18:37:30 2009 From: wxs at FreeBSD.org (Wesley Shields) Date: Sun Apr 5 18:37:38 2009 Subject: How to find out which ports contains a specified command. In-Reply-To: References: <20090405200614.GB5095@titania.njm.me.uk> Message-ID: <20090406011945.GA46113@atarininja.org> On Mon, Apr 06, 2009 at 01:45:43AM +0200, Alberto Villa wrote: > On Sun, Apr 5, 2009 at 10:06 PM, N.J. Mann wrote: > > adduser: /usr/sbin/adduser /usr/share/man/en.ISO8859-15/man8/adduser.8 /usr/src/usr.sbin/adduser > > > > So, it is part of the base system. ?This can be confirmed by searching > > the on-line manual, i.e. > > anyway, if you're looking for other programs, i can't remember if > there is any special way... i think i'd try something like: > cd /usr/ports && grep -i "bin/$yourcommand" -f */*/pkg-plist This makes two assumptions which are not always true: - It assumes $yourcommand lives in ${PREFIX}/bin. - It searches only pkg-plist. Not all ports install into ${PREFIX}/bin and not all ports use pkg-plist. If you want a more accurate search you're better off searching Makefile for the information in PLIST_FILES along with pkg-plist. It is worth noting that even this is not fool-proof since some ports use dynamic plist generation so the information is never in pkg-plist except for when the plist is built. IMO this is a short-coming with ports, and only getting more and more noticeable as we expand the number of ports. I have some ideas on how to address this if someone wants to ping me about it off list. -- WXS From manfred.lotz at arcor.de Sun Apr 5 20:40:53 2009 From: manfred.lotz at arcor.de (Manfred Lotz) Date: Sun Apr 5 20:40:59 2009 Subject: xorg loops In-Reply-To: <1238959921.1829.10.camel@balrog.2hip.net> References: <49D8D03B.8090302@arcor.de> <3a142e750904050919l1388b559t9bbd751546e239e7@mail.gmail.com> <1238957462.1829.8.camel@balrog.2hip.net> <49D90363.6010602@arcor.de> <1238959921.1829.10.camel@balrog.2hip.net> Message-ID: <49D979C2.3070509@arcor.de> Robert Noland wrote: > On Sun, 2009-04-05 at 21:15 +0200, Manfred Lotz wrote: > >> Robert Noland wrote: >> >>> On Sun, 2009-04-05 at 18:19 +0200, Paul B. Mahol wrote: >>> >>> >>>> On 4/5/09, Manfred Lotz wrote: >>>> >>>> >>>>> Hi all, >>>>> Using 8 current from time to time I have an xorg problem. >>>>> >>>>> Getting millions of those messages >>>>> >>>>> (II) Mouse autoprobe: Changing protocol to ExplorerPS/2 >>>>> (II) Mouse autoprobe: Changing protocol to ImPS/2 >>>>> >>>>> the system is unusable. No response from keyboard or mouse any more. >>>>> >>>>> >>>>> >>>>> Any idea, what I can do to prevent this from happining? >>>>> >>>>> >>>> Disable hal if it is enabled? >>>> >>>> >>> No, the issue isn't hal... >>> >>> robert. >>> >>> >>> >> But disabling HAL gave me the possibility to use moused again (as in >> older xorg times) which you recommended in the other reply. >> >> Anyway, I don't like the idea to have hal and dbus active as a >> prerequisite for running xorg. I just didn't know that I could get rid >> of hal. >> > > hald should work fine with moused now. > > Aah, ok. When I had both active some weeks ago I had strange behavior of keyboard and mouse. That's why I disabled moused. -- Manfred From julian at elischer.org Sun Apr 5 21:17:28 2009 From: julian at elischer.org (Julian Elischer) Date: Sun Apr 5 21:17:35 2009 Subject: Kip Macy In-Reply-To: <11619.11192.qm@web63903.mail.re1.yahoo.com> References: <11619.11192.qm@web63903.mail.re1.yahoo.com> Message-ID: <49D9826F.80502@elischer.org> Barney Cordoba wrote: > > > > --- On Tue, 3/31/09, Barrett Lyon wrote: > >> From: Barrett Lyon >> Subject: Kip Macy >> To: freebsd-current@freebsd.org >> Date: Tuesday, March 31, 2009, 7:24 PM >> I'm sure this is the wrong place to post this, but I >> thought I would share anyway: >> >> http://digg.com/linux_unix/FreeBSD_developer_s_life_destroyed_by_squatter_from_hell >> >> It's Kip's story from the other side, I thought >> this community may like to read it and spread the digg >> story. >> >> -Barrett > > I hate to interject politics into this, but this is what the entire > country will be like if Obama has his way. G*d help us. oh, well, now tell us what you really think.. > > Barney > > > > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" From tinderbox at freebsd.org Sun Apr 5 22:06:35 2009 From: tinderbox at freebsd.org (FreeBSD Tinderbox) Date: Sun Apr 5 22:06:42 2009 Subject: [head tinderbox] failure on ia64/ia64 Message-ID: <20090406050631.387B37302F@freebsd-current.sentex.ca> TB --- 2009-04-06 03:43:11 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2009-04-06 03:43:11 - starting HEAD tinderbox run for ia64/ia64 TB --- 2009-04-06 03:43:11 - cleaning the object tree TB --- 2009-04-06 03:43:34 - cvsupping the source tree TB --- 2009-04-06 03:43:34 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/ia64/ia64/supfile TB --- 2009-04-06 03:43:43 - building world TB --- 2009-04-06 03:43:43 - MAKEOBJDIRPREFIX=/obj TB --- 2009-04-06 03:43:43 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-04-06 03:43:43 - TARGET=ia64 TB --- 2009-04-06 03:43:43 - TARGET_ARCH=ia64 TB --- 2009-04-06 03:43:43 - TZ=UTC TB --- 2009-04-06 03:43:43 - __MAKE_CONF=/dev/null TB --- 2009-04-06 03:43:43 - cd /src TB --- 2009-04-06 03:43:43 - /usr/bin/make -B buildworld >>> World build started on Mon Apr 6 03:43:45 UTC 2009 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything [...] /src/sbin/routed/if.c: In function 'ifinit': /src/sbin/routed/if.c:710: warning: cast increases required alignment of target type /src/sbin/routed/if.c:719: warning: cast increases required alignment of target type /src/sbin/routed/if.c:777: warning: cast increases required alignment of target type /src/sbin/routed/if.c:818: warning: cast increases required alignment of target type /src/sbin/routed/if.c:831: warning: cast increases required alignment of target type /src/sbin/routed/if.c:846: warning: cast increases required alignment of target type /src/sbin/routed/if.c:865: warning: cast increases required alignment of target type *** Error code 1 Stop in /src/sbin/routed. *** Error code 1 Stop in /obj/ia64/src/rescue/rescue. *** Error code 1 Stop in /src/rescue/rescue. *** Error code 1 Stop in /src/rescue. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-04-06 05:06:31 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-04-06 05:06:31 - ERROR: failed to build world TB --- 2009-04-06 05:06:31 - 4077.53 user 329.91 system 4999.36 real http://tinderbox.des.no/tinderbox-head-HEAD-ia64-ia64.full From sobomax at FreeBSD.org Sun Apr 5 22:45:14 2009 From: sobomax at FreeBSD.org (Maxim Sobolev) Date: Sun Apr 5 22:45:21 2009 Subject: Kip Macy In-Reply-To: <49D9826F.80502@elischer.org> References: <11619.11192.qm@web63903.mail.re1.yahoo.com> <49D9826F.80502@elischer.org> Message-ID: <49D996C3.6000700@FreeBSD.org> Julian Elischer wrote: > Barney Cordoba wrote: >> >> >> >> --- On Tue, 3/31/09, Barrett Lyon wrote: >> >>> From: Barrett Lyon >>> Subject: Kip Macy >>> To: freebsd-current@freebsd.org >>> Date: Tuesday, March 31, 2009, 7:24 PM >>> I'm sure this is the wrong place to post this, but I >>> thought I would share anyway: >>> >>> http://digg.com/linux_unix/FreeBSD_developer_s_life_destroyed_by_squatter_from_hell >>> >>> >>> It's Kip's story from the other side, I thought >>> this community may like to read it and spread the digg >>> story. >>> >>> -Barrett >> >> I hate to interject politics into this, but this is what the entire >> country will be like if Obama has his way. G*d help us. > > oh, well, now tell us what you really think.. Stop, please. -current is not really the place to discuss politics. -Maxim From tinderbox at freebsd.org Sun Apr 5 23:03:39 2009 From: tinderbox at freebsd.org (FreeBSD Tinderbox) Date: Sun Apr 5 23:03:48 2009 Subject: [head tinderbox] failure on mips/mips Message-ID: <20090406060335.B18707302F@freebsd-current.sentex.ca> TB --- 2009-04-06 05:06:31 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2009-04-06 05:06:31 - starting HEAD tinderbox run for mips/mips TB --- 2009-04-06 05:06:31 - cleaning the object tree TB --- 2009-04-06 05:06:52 - cvsupping the source tree TB --- 2009-04-06 05:06:52 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/mips/mips/supfile TB --- 2009-04-06 05:07:01 - building world TB --- 2009-04-06 05:07:01 - MAKEOBJDIRPREFIX=/obj TB --- 2009-04-06 05:07:01 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-04-06 05:07:01 - TARGET=mips TB --- 2009-04-06 05:07:01 - TARGET_ARCH=mips TB --- 2009-04-06 05:07:01 - TZ=UTC TB --- 2009-04-06 05:07:01 - __MAKE_CONF=/dev/null TB --- 2009-04-06 05:07:01 - cd /src TB --- 2009-04-06 05:07:01 - /usr/bin/make -B buildworld >>> World build started on Mon Apr 6 05:07:02 UTC 2009 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything [...] /src/sbin/routed/if.c:846: warning: cast increases required alignment of target type /src/sbin/routed/if.c:846: warning: cast increases required alignment of target type /src/sbin/routed/if.c:846: warning: cast increases required alignment of target type /src/sbin/routed/if.c:846: warning: cast increases required alignment of target type /src/sbin/routed/if.c:846: warning: cast increases required alignment of target type /src/sbin/routed/if.c:846: warning: cast increases required alignment of target type /src/sbin/routed/if.c:865: warning: cast increases required alignment of target type /src/sbin/routed/if.c:954: warning: format '%ld' expects type 'long int', but argument 3 has type 'time_t' *** Error code 1 Stop in /src/sbin/routed. *** Error code 1 Stop in /src/sbin. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-04-06 06:03:35 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-04-06 06:03:35 - ERROR: failed to build world TB --- 2009-04-06 06:03:35 - 2620.77 user 309.95 system 3424.23 real http://tinderbox.des.no/tinderbox-head-HEAD-mips-mips.full From delphij at delphij.net Sun Apr 5 23:21:05 2009 From: delphij at delphij.net (Xin LI) Date: Sun Apr 5 23:21:11 2009 Subject: ddb can't use USB keyboard? Message-ID: <49D99F42.5040104@delphij.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, Did anyone used USB keyboard in ddb? It looks like that once I entered ddb, the keyboard would stop responding :( Cheers, - -- Xin LI http://www.delphij.net/ FreeBSD - The Power to Serve! -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.11 (FreeBSD) iEYEARECAAYFAknZn0EACgkQi+vbBBjt66AT9gCfbPPQthQi1I7cP798cUdY5U9Q 754AoJLYmTO8FZAR4JTzHK77vwj1glkc =/3Wg -----END PGP SIGNATURE----- From tinderbox at freebsd.org Mon Apr 6 00:10:11 2009 From: tinderbox at freebsd.org (FreeBSD Tinderbox) Date: Mon Apr 6 00:10:19 2009 Subject: [head tinderbox] failure on sparc64/sparc64 Message-ID: <20090406071007.E90967302F@freebsd-current.sentex.ca> TB --- 2009-04-06 06:03:35 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2009-04-06 06:03:35 - starting HEAD tinderbox run for sparc64/sparc64 TB --- 2009-04-06 06:03:35 - cleaning the object tree TB --- 2009-04-06 06:04:02 - cvsupping the source tree TB --- 2009-04-06 06:04:02 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/sparc64/sparc64/supfile TB --- 2009-04-06 06:04:14 - building world TB --- 2009-04-06 06:04:14 - MAKEOBJDIRPREFIX=/obj TB --- 2009-04-06 06:04:14 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-04-06 06:04:14 - TARGET=sparc64 TB --- 2009-04-06 06:04:14 - TARGET_ARCH=sparc64 TB --- 2009-04-06 06:04:14 - TZ=UTC TB --- 2009-04-06 06:04:14 - __MAKE_CONF=/dev/null TB --- 2009-04-06 06:04:14 - cd /src TB --- 2009-04-06 06:04:14 - /usr/bin/make -B buildworld >>> World build started on Mon Apr 6 06:04:15 UTC 2009 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything [...] /src/sbin/routed/if.c: In function 'ifinit': /src/sbin/routed/if.c:710: warning: cast increases required alignment of target type /src/sbin/routed/if.c:719: warning: cast increases required alignment of target type /src/sbin/routed/if.c:777: warning: cast increases required alignment of target type /src/sbin/routed/if.c:818: warning: cast increases required alignment of target type /src/sbin/routed/if.c:831: warning: cast increases required alignment of target type /src/sbin/routed/if.c:846: warning: cast increases required alignment of target type /src/sbin/routed/if.c:865: warning: cast increases required alignment of target type *** Error code 1 Stop in /src/sbin/routed. *** Error code 1 Stop in /obj/sparc64/src/rescue/rescue. *** Error code 1 Stop in /src/rescue/rescue. *** Error code 1 Stop in /src/rescue. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-04-06 07:10:07 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-04-06 07:10:07 - ERROR: failed to build world TB --- 2009-04-06 07:10:07 - 3078.65 user 314.27 system 3991.86 real http://tinderbox.des.no/tinderbox-head-HEAD-sparc64-sparc64.full From hartmut.brandt at dlr.de Mon Apr 6 00:54:36 2009 From: hartmut.brandt at dlr.de (Hartmut Brandt) Date: Mon Apr 6 00:54:42 2009 Subject: problem with nss_ldap In-Reply-To: <49D92586.6030803@sdf.lonestar.org> References: <49A69B74.1080201@sdf.lonestar.org> <49A97F2E.3030005@sdf.lonestar.org> <20090306213531.G60465@beagle.kn.op.dlr.de> <20090306211650.GD41617@deviant.kiev.zoral.com.ua> <20090306222433.GF41617@deviant.kiev.zoral.com.ua> <20090310114131.GD41617@deviant.kiev.zoral.com.ua> <70D16F57-F7E3-4CDA-BCD5-5D79B566510B@rabson.org> <49B69C36.3010307@sdf.lonestar.org> <49D92586.6030803@sdf.lonestar.org> Message-ID: <49D9B539.9060700@dlr.de> Tom McLaughlin wrote: > Tom McLaughlin wrote, On 03/10/2009 12:58 PM: >> Doug Rabson wrote: >>> On 10 Mar 2009, at 11:41, Kostik Belousov wrote: >>> >>>> On Tue, Mar 10, 2009 at 10:38:51AM +0000, Doug Rabson wrote: >>>>> On 6 Mar 2009, at 22:24, Kostik Belousov wrote: >>>>> >>>>>> On Fri, Mar 06, 2009 at 05:00:49PM -0500, tmclaugh@sdf.lonestar.org >>>>>> wrote: >>>>>>>> On Fri, Mar 06, 2009 at 09:39:31PM +0100, Hartmut Brandt wrote: >>>>>>>>> Hi Tom, >>>>>>>>> >>>>>>>>> On Sat, 28 Feb 2009, Tom McLaughlin wrote: >>>>>>>>> >>>>>>>>> TM>Tom McLaughlin wrote: >>>>>>>>> TM>> Harti Brandt wrote: >>>>>>>>> TM>> > On Sun, 18 Jan 2009, Hartmut.Brandt@dlr.de wrote: > >> Okay, attached is a patch to nss_ldap. On -CURRENT I have changed the >> CONFIGURE_ARG to use "--enable-configurable-krb5-ccname-gssapi" >> instead of "--enable-configurable-krb5-ccname-env" which fixes Harti's >> initial problem with apps like cron failing. It will also make >> nss_ldap link against libgssapi and libgssapi_krb5. I still have one >> lingering issue though at least things work. >> >> [tom@freebsd-8-amd64 tom]$ getent passwd tom >> dlopen: /usr/lib/libgssapi_spnego.so.10: Undefined symbol >> "GSS_C_NT_HOSTBASED_SERVICE" >> tom:x:10001:10001:Tom McLaughlin:/home/tom:/bin/sh >> > > Hey, just curious if there's anything that can be done about the one > lingering issue I have above with: > > dlopen: /usr/lib/libgssapi_spnego.so.10: Undefined symbol > "GSS_C_NT_HOSTBASED_SERVICE" > > Got back from vacation and happen to go through my -CURRENT box's > mailbox and cron has flooded my inbox with emails because of this. Would > be nice to make this go away. :) Yes. I get this on every 'ls -l' and on 'vi' which is kind of annoying. But I have not enough GSSAPI-foo... harti From matheus at eternamente.info Mon Apr 6 00:57:34 2009 From: matheus at eternamente.info (Nenhum_de_Nos) Date: Mon Apr 6 00:57:41 2009 Subject: Booting from usb hard disk Message-ID: On Mon, March 30, 2009 03:10, Andrew Thompson wrote: > On Tue, Mar 24, 2009 at 03:49:32AM -0500, Robert Noland wrote: >> On Mon, 2009-03-23 at 19:40 -0300, Nenhum_de_Nos wrote: >> > On Mon, March 23, 2009 07:36, Robert Noland wrote: >> > > So I have my i386 install on a usb hard disk, which I can only boot >> on >> > > one machine now. The one machine that I can make work has a bios >> option >> > > that reads "BIOS ehci handoff". This used to work with the old usb stack. The machines that it doesn't work on, boot the kernel, but >> fail >> > > to mount root, giving me the forbidding mountroot> prompt, which is immediately followed by the message saying that da0 is attached. >> da0 is >> > > however not listed in the available boot devices list. I tried >> playing >> > > around with the timeout in vfs_mount.c, but that didn't seem to have >> any >> > > impact. It has been suggested that this may be a "geom" timeout, >> but I >> > > don't know anything about the boot system really. >> > >> > I had problem a while ago with via mini itx hardware, that was quite close. If I try boot from usb (installed in usb hdd), I get to the >> point >> > of loader not finding my disk. >> > >> > I then used a small flash disk attached to the ata (44 pin ide) >> channel >> > and formatted /boot in there. this way I get to the point of mount >> root >> > you said, and da0 not being alive soon enough to mount root. list >> disks >> > also couldn't find da0 though. >> > >> > I tried current from that time, and no good. >> > >> > if this is solved, I'll be happy to try whatever patch to current. (as >> > long as I can install it from another box/or its ata channel, as it >> can't >> > boot vanilla 7.1R) >> So, my solution was to set kern.cam.scsi_delay=10000 >> in /boot/loader.conf > > The following patch should work. It creates interleaving root hold tokens from the CAM probe to disk_create and geom providor tasting. I had to add a malloc type flag as sleeping isnt allowed at the point I added the token alloc in CAM. > > http://people.freebsd.org/~thompsa/root_wait.diff > > It needs review by the various geom/cam ppls. > > > Andrew phoenix# patch < ../root_wait.diff Hmm... Looks like a unified diff to me... The text leading up to this was: -------------------------- |Index: kern/vfs_mount.c |=================================================================== |--- kern/vfs_mount.c (revision 190540) |+++ kern/vfs_mount.c (working copy) -------------------------- Patching file kern/vfs_mount.c using Plan A... Reversed (or previously applied) patch detected! Assume -R? [y] Hunk #1 succeeded at 1353. Hmm... The next patch looks like a unified diff to me... The text leading up to this was: -------------------------- |Index: cam/cam_xpt.c |=================================================================== |--- cam/cam_xpt.c (revision 190540) |+++ cam/cam_xpt.c (working copy) -------------------------- Patching file cam/cam_xpt.c using Plan A... Reversed (or previously applied) patch detected! Assume -R? [y] Hunk #1 succeeded at 5139. Hunk #2 succeeded at 5201. Hunk #3 succeeded at 5232. Hunk #4 succeeded at 5240. Hunk #5 succeeded at 5353. Hunk #6 succeeded at 5372. Hmm... The next patch looks like a unified diff to me... The text leading up to this was: -------------------------- |Index: dev/pccbb/pccbb_pci.c |=================================================================== |--- dev/pccbb/pccbb_pci.c (revision 190540) |+++ dev/pccbb/pccbb_pci.c (working copy) -------------------------- Patching file dev/pccbb/pccbb_pci.c using Plan A... Reversed (or previously applied) patch detected! Assume -R? [y] Hunk #1 succeeded at 439. Hmm... The next patch looks like a unified diff to me... The text leading up to this was: -------------------------- |Index: dev/usb/controller/usb_controller.c |=================================================================== |--- dev/usb/controller/usb_controller.c (revision 190540) |+++ dev/usb/controller/usb_controller.c (working copy) -------------------------- Patching file dev/usb/controller/usb_controller.c using Plan A... Reversed (or previously applied) patch detected! Assume -R? [y] Hunk #1 succeeded at 115. Hmm... The next patch looks like a unified diff to me... The text leading up to this was: -------------------------- |Index: geom/mirror/g_mirror.c |=================================================================== |--- geom/mirror/g_mirror.c (revision 190540) |+++ geom/mirror/g_mirror.c (working copy) -------------------------- Patching file geom/mirror/g_mirror.c using Plan A... Reversed (or previously applied) patch detected! Assume -R? [y] Hunk #1 succeeded at 2907. Hmm... The next patch looks like a unified diff to me... The text leading up to this was: -------------------------- |Index: geom/geom_disk.c |=================================================================== |--- geom/geom_disk.c (revision 190540) |+++ geom/geom_disk.c (working copy) -------------------------- Patching file geom/geom_disk.c using Plan A... Reversed (or previously applied) patch detected! Assume -R? [y] Hunk #1 succeeded at 381. Hunk #2 succeeded at 467. Hmm... The next patch looks like a unified diff to me... The text leading up to this was: -------------------------- |Index: geom/geom_disk.h |=================================================================== |--- geom/geom_disk.h (revision 190540) |+++ geom/geom_disk.h (working copy) -------------------------- Patching file geom/geom_disk.h using Plan A... Reversed (or previously applied) patch detected! Assume -R? [y] Hunk #1 succeeded at 88. Hmm... The next patch looks like a unified diff to me... The text leading up to this was: -------------------------- |Index: geom/raid3/g_raid3.c |=================================================================== |--- geom/raid3/g_raid3.c (revision 190540) |+++ geom/raid3/g_raid3.c (working copy) -------------------------- Patching file geom/raid3/g_raid3.c using Plan A... Reversed (or previously applied) patch detected! Assume -R? [y] Hunk #1 succeeded at 3193. Hmm... The next patch looks like a unified diff to me... The text leading up to this was: -------------------------- |Index: geom/geom_subr.c |=================================================================== |--- geom/geom_subr.c (revision 190540) |+++ geom/geom_subr.c (working copy) -------------------------- Patching file geom/geom_subr.c using Plan A... Reversed (or previously applied) patch detected! Assume -R? [y] Hunk #1 succeeded at 545. Hunk #2 succeeded at 581. Hmm... The next patch looks like a unified diff to me... The text leading up to this was: -------------------------- |Index: geom/part/g_part.c |=================================================================== |--- geom/part/g_part.c (revision 190540) |+++ geom/part/g_part.c (working copy) -------------------------- Patching file geom/part/g_part.c using Plan A... Reversed (or previously applied) patch detected! Assume -R? [y] Hunk #1 succeeded at 1474. Hmm... The next patch looks like a unified diff to me... The text leading up to this was: -------------------------- |Index: geom/journal/g_journal.c |=================================================================== |--- geom/journal/g_journal.c (revision 190540) |+++ geom/journal/g_journal.c (working copy) -------------------------- Patching file geom/journal/g_journal.c using Plan A... Reversed (or previously applied) patch detected! Assume -R? [y] Hunk #1 succeeded at 2310. Hmm... The next patch looks like a unified diff to me... The text leading up to this was: -------------------------- |Index: geom/geom.h |=================================================================== |--- geom/geom.h (revision 190540) |+++ geom/geom.h (working copy) -------------------------- Patching file geom/geom.h using Plan A... Reversed (or previously applied) patch detected! Assume -R? [y] Hunk #1 succeeded at 193. Hmm... The next patch looks like a unified diff to me... The text leading up to this was: -------------------------- |Index: cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_ioctl.c |=================================================================== |--- cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_ioctl.c (revision 190540) |+++ cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_ioctl.c (working copy) -------------------------- Patching file cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_ioctl.c using Plan A... Reversed (or previously applied) patch detected! Assume -R? [y] Hunk #1 succeeded at 3087. Hmm... The next patch looks like a unified diff to me... The text leading up to this was: -------------------------- |Index: sys/systm.h |=================================================================== |--- sys/systm.h (revision 190540) |+++ sys/systm.h (working copy) -------------------------- Patching file sys/systm.h using Plan A... Reversed (or previously applied) patch detected! Assume -R? [y] Hunk #1 succeeded at 325. done phoenix# done. and then I got to boot. (thanks, three months to get here !) but then more info. I can't boot from usb in here, this itx has a small 32MB flash in ide I use to boot from. I put there /boot and some files from kernel (32MB is can't keep all files). now it can't boot by itself, it fails when mounting root, but da0s1a is there and simple: ufs:da0s1a does the job. dmesg attached. I'll try to find out how to make it boot by itself now :) thanks to all :D matheus phoenix# dmesg Copyright (c) 1992-2009 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 is a registered trademark of The FreeBSD Foundation. FreeBSD 8.0-CURRENT #0: Sun Apr 5 02:39:15 BRT 2009 root@phoenix.apartnet:/usr/obj/usr/src/sys/Phoenix8 Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Transmeta(tm) Crusoe(tm) Processor TM5700 (798.13-MHz 586-class CPU) Origin = "GenuineTMx86" Id = 0x543 Stepping = 3 Features=0x84893f real memory = 270532608 (258 MB) avail memory = 231632896 (220 MB) kbd1 at kbdmux0 pcib0: pcibus 0 on motherboard pir0: on motherboard pci0: on pcib0 pci0: at device 0.1 (no driver attached) pci0: at device 0.2 (no driver attached) pci0: at device 0.3 (no driver attached) uhci0: port 0xe000-0xe01f irq 15 at device 9.0 on pci0 uhci0: [ITHREAD] uhci0: LegSup = 0x201a usbus0: on uhci0 uhci1: port 0xe100-0xe11f irq 5 at device 9.1 on pci0 uhci1: [ITHREAD] uhci1: LegSup = 0x2010 usbus1: on uhci1 ehci0: mem 0xe8131000-0xe81310ff irq 10 at device 9.2 on pci0 ehci0: [ITHREAD] usbus2: EHCI version 1.0 usbus2: on ehci0 vgapci0: port 0xe200-0xe2ff mem 0xe0000000-0xe7ffffff,0xe8120000-0xe812ffff irq 11 at device 13.0 on pci0 isab0: at device 17.0 on pci0 isa0: on isab0 atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xe300-0xe30f at device 17.1 on pci0 ata0: on atapci0 ata0: [ITHREAD] ata1: on atapci0 ata1: [ITHREAD] pci0: at device 17.4 (no driver attached) vr0: port 0xe600-0xe6ff mem 0xe8130000-0xe81300ff irq 15 at device 18.0 on pci0 vr0: Quirks: 0x0 vr0: Revision: 0x51 miibus0: on vr0 ukphy0: PHY 1 on miibus0 ukphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto vr0: Ethernet address: 00:11:85:e3:2a:17 vr0: [ITHREAD] cpu0 on motherboard pmtimer0 on isa0 atrtc0: at port 0x70-0x71 irq 8 pnpid PNP0b00 on isa0 atkbdc0: at port 0x60,0x64 irq 1 pnpid PNP0303 on isa0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] atkbd0: [ITHREAD] unknown: can't assign resources (memory) orm0: at iomem 0xc0000-0xc8fff,0xcc000-0xd5fff pnpid ORM0000 on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 ppc0: parallel port not found. unknown: can't assign resources (memory) Timecounter "TSC" frequency 798130362 Hz quality 800 Timecounters tick every 1.000 msec usbus0: 12Mbps Full Speed USB v1.0 usbus1: 12Mbps Full Speed USB v1.0 usbus2: 480Mbps High Speed USB v2.0 ugen0.1: at usbus0 uhub0: on usbus0 ugen1.1: at usbus1 uhub1: on usbus1 ugen2.1: at usbus2 uhub2: on usbus2 ad0: 30MB <32MB ATA Flash Disk ADBA217H> at ata0-master PIO4 GEOM_LABEL: Label for provider ad0 is ufsid/49adccdba5f8e304. GEOM_LABEL: Label for provider ad0 is ufs/flash. GEOM_LABEL: Label for provider ad0s1 is ufsid/49adce490693435d. uhub0: 2 ports with 2 removable, self powered Root mount waiting for: usbus2 usbus1 uhub1: 2 ports with 2 removable, self powered Root mount waiting for: usbus2 uhub2: 4 ports with 4 removable, self powered Root mount waiting for: usbus2 ugen2.2: at usbus2 umass0: on usbus2 umass0: SCSI over Bulk-Only; quirks = 0x408c Root mount waiting for: usbus2 umass0:0:0:-1: Attached to scbus0 da0 at umass-sim0 bus 0 target 0 lun 0 da0: Fixed Direct Access SCSI-0 device da0: 40.000MB/s transfers da0: 6149MB (12594960 512 byte sectors: 255H 63S/T 784C) GEOM_LABEL: Label for provider da0s1a is ufsid/49d77edb683149d9. GEOM_LABEL: Label for provider da0s1d is ufsid/49d77eddb6efc899. GEOM_LABEL: Label for provider da0s1e is ufsid/49d77edcee1ceb99. GEOM_LABEL: Label for provider da0s1f is ufsid/49d77edc7a6dba2b. Root mount waiting for: usbus2 ugen2.3: at usbus2 umass1: on usbus2 umass1: 8070i (ATAPI) over Bulk-Only; quirks = 0x008c Root mount waiting for: usbus2 umass1:1:1:-1: Attached to scbus1 (probe0:umass-sim1:1:0:0): TEST UNIT READY. CDB: 0 0 0 0 0 0 (probe0:umass-sim1:1:0:0): CAM Status: SCSI Status Error (probe0:umass-sim1:1:0:0): SCSI Status: Check Condition (probe0:umass-sim1:1:0:0): NOT READY asc:3a,0 (probe0:umass-sim1:1:0:0): Medium not present (probe0:umass-sim1:1:0:0): Unretryable error Manual root filesystem specification: : Mount using cd0 at umass-sim1 bus 1 target 0 lun 0 cd0: Removable CD-ROM SCSI-0 device cd0: 40.000MB/s transfers cd0: Attempt to query device size failed: NOT READY, Medium not present filesystem eg. ufs:da0s1a ? List valid disk boot devices Abort manual input mountroot> ufs:da0s1a Trying to mount root from ufs:da0s1a GEOM_LABEL: Label ufsid/49d77edb683149d9 removed. GEOM_LABEL: Label for provider da0s1a is ufsid/49d77edb683149d9. GEOM_LABEL: Label ufsid/49d77edcee1ceb99 removed. GEOM_LABEL: Label for provider da0s1e is ufsid/49d77edcee1ceb99. GEOM_LABEL: Label ufsid/49d77edc7a6dba2b removed. GEOM_LABEL: Label for provider da0s1f is ufsid/49d77edc7a6dba2b. GEOM_LABEL: Label ufsid/49d77eddb6efc899 removed. GEOM_LABEL: Label for provider da0s1d is ufsid/49d77eddb6efc899. GEOM_LABEL: Label ufsid/49d77edb683149d9 removed. GEOM_LABEL: Label ufsid/49d77edcee1ceb99 removed. GEOM_LABEL: Label ufsid/49d77edc7a6dba2b removed. GEOM_LABEL: Label ufsid/49d77eddb6efc899 removed. -- We will call you cygnus, The God of balance you shall be From tinderbox at freebsd.org Mon Apr 6 01:13:30 2009 From: tinderbox at freebsd.org (FreeBSD Tinderbox) Date: Mon Apr 6 01:13:47 2009 Subject: [head tinderbox] failure on sparc64/sun4v Message-ID: <20090406081325.B316F7302F@freebsd-current.sentex.ca> TB --- 2009-04-06 07:10:08 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2009-04-06 07:10:08 - starting HEAD tinderbox run for sparc64/sun4v TB --- 2009-04-06 07:10:08 - cleaning the object tree TB --- 2009-04-06 07:10:55 - cvsupping the source tree TB --- 2009-04-06 07:10:55 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/sparc64/sun4v/supfile TB --- 2009-04-06 07:11:03 - building world TB --- 2009-04-06 07:11:03 - MAKEOBJDIRPREFIX=/obj TB --- 2009-04-06 07:11:03 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-04-06 07:11:03 - TARGET=sun4v TB --- 2009-04-06 07:11:03 - TARGET_ARCH=sparc64 TB --- 2009-04-06 07:11:03 - TZ=UTC TB --- 2009-04-06 07:11:03 - __MAKE_CONF=/dev/null TB --- 2009-04-06 07:11:03 - cd /src TB --- 2009-04-06 07:11:03 - /usr/bin/make -B buildworld >>> World build started on Mon Apr 6 07:11:05 UTC 2009 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything [...] /src/sbin/routed/if.c: In function 'ifinit': /src/sbin/routed/if.c:710: warning: cast increases required alignment of target type /src/sbin/routed/if.c:719: warning: cast increases required alignment of target type /src/sbin/routed/if.c:777: warning: cast increases required alignment of target type /src/sbin/routed/if.c:818: warning: cast increases required alignment of target type /src/sbin/routed/if.c:831: warning: cast increases required alignment of target type /src/sbin/routed/if.c:846: warning: cast increases required alignment of target type /src/sbin/routed/if.c:865: warning: cast increases required alignment of target type *** Error code 1 Stop in /src/sbin/routed. *** Error code 1 Stop in /obj/sun4v/src/rescue/rescue. *** Error code 1 Stop in /src/rescue/rescue. *** Error code 1 Stop in /src/rescue. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-04-06 08:13:25 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-04-06 08:13:25 - ERROR: failed to build world TB --- 2009-04-06 08:13:25 - 3060.02 user 314.96 system 3797.41 real http://tinderbox.des.no/tinderbox-head-HEAD-sparc64-sun4v.full From rizzo at iet.unipi.it Mon Apr 6 01:19:54 2009 From: rizzo at iet.unipi.it (Luigi Rizzo) Date: Mon Apr 6 01:20:00 2009 Subject: stale CPU_DISABLE_CMPXCHG in atomic.h ? Message-ID: <20090406082455.GA3358@onelab2.iet.unipi.it> It seems to me that there is no reason to keep the CPU_DISABLE_CMPXCHG option around in atomic.h -- the only reason, mentioned in sys/i386/conf/NOTES, was compatibility with old versions of VMware, long since fixed. Any objections if i remove it ? cheers luigi From rizzo at iet.unipi.it Mon Apr 6 01:27:37 2009 From: rizzo at iet.unipi.it (Luigi Rizzo) Date: Mon Apr 6 01:27:45 2009 Subject: missing atomic_exchg_*() in the atomic.h API ? Message-ID: <20090406083238.GB3358@onelab2.iet.unipi.it> while looking at the functions in atomic.h i noticed that there seems to be no atomic_exchg_*() in the API, though this is a supported function in most/all supported archiectures, and a useful function. We do have atomic_readandclear() which uses the same underlying CPU instruction. Again, any objection if i add it ? cheers luigi From gary.jennejohn at freenet.de Mon Apr 6 01:52:14 2009 From: gary.jennejohn at freenet.de (Gary Jennejohn) Date: Mon Apr 6 01:52:21 2009 Subject: How to find out which ports contains a specified command. In-Reply-To: <20090406011945.GA46113@atarininja.org> References: <20090405200614.GB5095@titania.njm.me.uk> <20090406011945.GA46113@atarininja.org> Message-ID: <20090406105210.783710eb@ernst.jennejohn.org> On Sun, 5 Apr 2009 21:19:45 -0400 Wesley Shields wrote: > On Mon, Apr 06, 2009 at 01:45:43AM +0200, Alberto Villa wrote: > > On Sun, Apr 5, 2009 at 10:06 PM, N.J. Mann wrote: > > > adduser: /usr/sbin/adduser /usr/share/man/en.ISO8859-15/man8/adduser.8 /usr/src/usr.sbin/adduser > > > > > > So, it is part of the base system. ?This can be confirmed by searching > > > the on-line manual, i.e. > > > > anyway, if you're looking for other programs, i can't remember if > > there is any special way... i think i'd try something like: > > cd /usr/ports && grep -i "bin/$yourcommand" -f */*/pkg-plist > > This makes two assumptions which are not always true: > > - It assumes $yourcommand lives in ${PREFIX}/bin. > - It searches only pkg-plist. > > Not all ports install into ${PREFIX}/bin and not all ports use > pkg-plist. If you want a more accurate search you're better off > searching Makefile for the information in PLIST_FILES along with > pkg-plist. It is worth noting that even this is not fool-proof since > some ports use dynamic plist generation so the information is never in > pkg-plist except for when the plist is built. > > IMO this is a short-coming with ports, and only getting more and more > noticeable as we expand the number of ports. I have some ideas on how > to address this if someone wants to ping me about it off list. > /usr/ports/ports-mgmt/portsearch --- Gary Jennejohn From lars.engels at 0x20.net Mon Apr 6 02:17:07 2009 From: lars.engels at 0x20.net (Lars Engels) Date: Mon Apr 6 02:17:14 2009 Subject: How to find out which ports contains a specified command. In-Reply-To: <20090406105210.783710eb@ernst.jennejohn.org> References: <20090405200614.GB5095@titania.njm.me.uk> <20090406011945.GA46113@atarininja.org> <20090406105210.783710eb@ernst.jennejohn.org> Message-ID: <20090406111705.ejkvku4i0444cgsw@0x20.net> Quoting Gary Jennejohn : > On Sun, 5 Apr 2009 21:19:45 -0400 > Wesley Shields wrote: > >> On Mon, Apr 06, 2009 at 01:45:43AM +0200, Alberto Villa wrote: >> > On Sun, Apr 5, 2009 at 10:06 PM, N.J. Mann wrote: >> > > adduser: /usr/sbin/adduser >> /usr/share/man/en.ISO8859-15/man8/adduser.8 /usr/src/usr.sbin/adduser >> > > >> > > So, it is part of the base system. ?This can be confirmed by searching >> > > the on-line manual, i.e. >> > >> > anyway, if you're looking for other programs, i can't remember if >> > there is any special way... i think i'd try something like: >> > cd /usr/ports && grep -i "bin/$yourcommand" -f */*/pkg-plist >> >> This makes two assumptions which are not always true: >> >> - It assumes $yourcommand lives in ${PREFIX}/bin. >> - It searches only pkg-plist. >> >> Not all ports install into ${PREFIX}/bin and not all ports use >> pkg-plist. If you want a more accurate search you're better off >> searching Makefile for the information in PLIST_FILES along with >> pkg-plist. It is worth noting that even this is not fool-proof since >> some ports use dynamic plist generation so the information is never in >> pkg-plist except for when the plist is built. >> >> IMO this is a short-coming with ports, and only getting more and more >> noticeable as we expand the number of ports. I have some ideas on how >> to address this if someone wants to ping me about it off list. >> > > /usr/ports/ports-mgmt/portsearch Or fast and online: http://www.secnetix.de/tools/porgle/porgle.py -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: PGP Digital Signature Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20090406/0948a3b2/attachment.pgp From hselasky at c2i.net Mon Apr 6 03:50:29 2009 From: hselasky at c2i.net (Hans Petter Selasky) Date: Mon Apr 6 03:50:36 2009 Subject: 8-current and usb2 code In-Reply-To: <0b8071fb47497944952c3bf5d8e4dada.squirrel@cygnus.homeunix.com> References: <0b8071fb47497944952c3bf5d8e4dada.squirrel@cygnus.homeunix.com> Message-ID: <200904061252.57470.hselasky@c2i.net> On Monday 06 April 2009, Nenhum_de_Nos wrote: > umass1: ?8070i (ATAPI) over Bulk-Only; quirks = 0x008c Your device is marked with quirks. Maybe the quirks are wrong. Compare the quirk table in umass.c between 7.x and 8.x. --HPS From hselasky at c2i.net Mon Apr 6 03:51:41 2009 From: hselasky at c2i.net (Hans Petter Selasky) Date: Mon Apr 6 03:51:48 2009 Subject: ddb can't use USB keyboard? In-Reply-To: <49D99F42.5040104@delphij.net> References: <49D99F42.5040104@delphij.net> Message-ID: <200904061254.10288.hselasky@c2i.net> On Monday 06 April 2009, Xin LI wrote: > Hi, > > Did anyone used USB keyboard in ddb? It looks like that once I entered > ddb, the keyboard would stop responding :( > > Cheers, Using the USB keyboard in DDB is currently not supported in 8-current. --HPS From gelraen.ua at gmail.com Mon Apr 6 05:21:20 2009 From: gelraen.ua at gmail.com (Maxim Ignatenko) Date: Mon Apr 6 05:21:29 2009 Subject: [patch] matching IPv4 broadcast packets in ipfw Message-ID: >From my point of view it can be useful only on laptops, where you don't know exact broadcast addresses for all situations, but still want to deny/allow broadcast packets. Maybe I've missed something, then, please, correct me :) P.S.: another idea - maybe would be better to add it as possible value for dst-ip instead of rule option P.P.S.: before adding two "== NULL" in ip_fw2.c I had often kernel panics, even without broadcast option in ruleset. I would be very glad if someone can explain these to me. Patch itself: --- sys/netinet/ip_fw2.c.orig 2009-04-05 20:43:08.000000000 +0300 +++ sys/netinet/ip_fw2.c 2009-04-06 09:55:04.000000000 +0300 @@ -3131,6 +3131,27 @@ mtag->m_tag_id <= p[1]; } break; + case O_BROADCAST: + if (is_ipv4) + { + struct ifnet *ifp; + ifp=(oif ? oif : m->m_pkthdr.rcvif); + if (ifp == NULL || + (ifp->if_flags | IFF_BROADCAST) == 0) + break; + struct ifaddr *ia; + TAILQ_FOREACH(ia, &ifp->if_addrhead, ifa_link) { + if (ia->ifa_broadaddr == NULL || + ia->ifa_broadaddr->sa_family != AF_INET) + continue; + if (((struct sockaddr_in *)(ia->ifa_broadaddr))-> + sin_addr.s_addr == dst_ip.s_addr) { + match=1; + break; + } + } + } + break; } /* @@ -3897,6 +3918,7 @@ case O_IN: case O_FRAG: case O_DIVERTED: + case O_BROADCAST: case O_IPOPT: case O_IPTOS: case O_IPPRECEDENCE: --- sys/netinet/ip_fw.h.orig 2009-04-05 21:41:08.000000000 +0300 +++ sys/netinet/ip_fw.h 2009-04-05 21:46:23.000000000 +0300 @@ -179,6 +179,8 @@ O_SETFIB, /* arg1=FIB number */ O_FIB, /* arg1=FIB desired fib number */ + O_BROADCAST, /* matches IP packets sent on broadcast address */ + O_LAST_OPCODE /* not an opcode! */ }; --- sbin/ipfw/ipfw2.c.orig 2009-04-05 21:23:38.000000000 +0300 +++ sbin/ipfw/ipfw2.c 2009-04-06 09:25:39.000000000 +0300 @@ -291,6 +291,7 @@ { "src-ipv6", TOK_SRCIP6}, { "src-ip6", TOK_SRCIP6}, { "//", TOK_COMMENT }, + { "broadcast", TOK_BROADCAST}, { "not", TOK_NOT }, /* pseudo option */ { "!", /* escape ? */ TOK_NOT }, /* pseudo option */ @@ -1506,6 +1507,10 @@ print_newports((ipfw_insn_u16 *)cmd, 0, O_TAGGED); break; + + case O_BROADCAST: + printf(" broadcast"); + break; default: printf(" [opcode %d len %d]", @@ -3455,6 +3460,10 @@ ac = 0; break; + case TOK_BROADCAST: + fill_cmd(cmd, O_BROADCAST, 0, 0); + break; + case TOK_TAGGED: if (ac > 0 && strpbrk(*av, "-,")) { if (!add_ports(cmd, *av, 0, O_TAGGED)) --- sbin/ipfw/ipfw2.h.orig 2009-04-05 21:23:47.000000000 +0300 +++ sbin/ipfw/ipfw2.h 2009-04-05 21:27:22.000000000 +0300 @@ -141,6 +141,7 @@ TOK_ANTISPOOF, TOK_IPSEC, TOK_COMMENT, + TOK_BROADCAST, TOK_PLR, TOK_NOERROR, --- sbin/ipfw/ipfw.8.orig 2009-04-06 02:10:47.000000000 +0300 +++ sbin/ipfw/ipfw.8 2009-04-06 02:13:54.000000000 +0300 @@ -1135,6 +1135,8 @@ .It Cm bridged Alias for .Cm layer2 . +.It Cm broadcast +Matches broadcast packets on non-point-to-point interfaces. .It Cm diverted Matches only packets generated by a divert socket. .It Cm diverted-loopback From avg at icyb.net.ua Mon Apr 6 07:28:07 2009 From: avg at icyb.net.ua (Andriy Gapon) Date: Mon Apr 6 07:28:15 2009 Subject: ichwd: option to globally disable SMI Message-ID: <49DA1173.1080606@icyb.net.ua> Our ichwd driver attempts to disable TCO SMI generation to avoid potentially unhelpful SMI handler's handling of watchdog timeout. Recent ICH versions allow TCO SMI bit to be locked down (typically by BIOS), so that it can not be changed later. ichwd driver at present doesn't check result of changing the bit, so it doesn't report a failure. If the bit is locked and SMI handler is indeed unhelpful the only remaining possibility is to try to disable SMI completely. This bit too can be locked, but there is a chance that it is not. I am attaching a patch that makes ichwd check and report result of SMI bit operations and also try to disable SMI globally if permitted by hw.ichwd.use_global_smi tunable. This patch could be useful to you if the following two conditions are met: 1. existing ichwd driver successfully attaches and does not produce any errors/warnings; 2. kill -9 on watchdogd doesn't result in machine being rebooted after timeout; I am using this patch on DG33TL motherboard for couple of weeks now. I do not see any side-effects from disabling SMI and watchdog works as expected. P.S. I tried to contact Intel's customer support about my problem and I was told that watchdog is supported by Intel only on Extreme Edition motherboards, which my motherboard is not. I wonder if anybody here uses FreeBSD with such a motherboard and ichwd works properly indeed. -- Andriy Gapon -------------- next part -------------- diff --git a/sys/dev/ichwd/ichwd.c b/sys/dev/ichwd/ichwd.c index 35f8b5f..a4387a2 100644 --- a/sys/dev/ichwd/ichwd.c +++ b/sys/dev/ichwd/ichwd.c @@ -62,6 +62,7 @@ __FBSDID("$FreeBSD$"); #include #include #include +#include #include #include #include @@ -72,6 +73,14 @@ __FBSDID("$FreeBSD$"); #include + +static int use_global_smi = 0; + +SYSCTL_NODE(_hw, OID_AUTO, ichwd, CTLFLAG_RD, 0, "ichwd driver global parameters"); +TUNABLE_INT("hw.ichwd.use_global_smi", &use_global_smi); +SYSCTL_INT(_hw_ichwd, OID_AUTO, use_global_smi, CTLFLAG_RDTUN, &use_global_smi, 0, + "ichwd may try to change global SMI Enable bit if TCO SMI bit is locked"); + static struct ichwd_device ichwd_devices[] = { { DEVICEID_82801AA, "Intel 82801AA watchdog timer", 1 }, { DEVICEID_82801AB, "Intel 82801AB watchdog timer", 1 }, @@ -141,26 +150,108 @@ static devclass_t ichwd_devclass; device_printf(dev, __VA_ARGS__);\ } while (0) +/* + * Disable the watchdog timeout SMI handler. + * + * Apparently, some BIOSes install handlers that reset or disable the + * watchdog timer instead of resetting the system, so we disable the SMI + * (by clearing the SMI_TCO_EN bit of the SMI_EN register) to prevent this + * from happening. + */ static __inline void -ichwd_intr_enable(struct ichwd_softc *sc) +ichwd_smi_disable(struct ichwd_softc *sc) { - ichwd_write_smi_4(sc, SMI_EN, ichwd_read_smi_4(sc, SMI_EN) & ~SMI_TCO_EN); + uint32_t val; + + val = ichwd_read_smi_4(sc, SMI_EN); + + /* check if either TCO SMI is disabled or SMI is disabled globally */ + if ((val & (SMI_TCO_EN | SMI_GBL_EN)) != (SMI_TCO_EN | SMI_GBL_EN)) + return; + /* first try to disabled TCO SMI */ + val &= ~SMI_TCO_EN; + ichwd_write_smi_4(sc, SMI_EN, val); + + /* check if TCO SMI got disabled */ + val = ichwd_read_smi_4(sc, SMI_EN); + if ((val & SMI_TCO_EN) == 0) + return; + printf("could not disable TCO SMI, bit might be locked by BIOS\n"); + + /* check if user allowed to fiddle with global SMI settings */ + if (!use_global_smi) + return; + + /* try to disable SMI globally */ + val &= ~SMI_GBL_EN; + ichwd_write_smi_4(sc, SMI_EN, val); + + /* check results */ + val = ichwd_read_smi_4(sc, SMI_EN); + if (val & SMI_GBL_EN) + printf("could not disable SMI globally, bit might be locked by BIOS\n"); + else + printf("disabled SMI globally (permitted by use_global_smi tunable)\n"); } +/* + * Enable the watchdog timeout SMI handler. See above for details. + */ static __inline void -ichwd_intr_disable(struct ichwd_softc *sc) +ichwd_smi_enable(struct ichwd_softc *sc) { - ichwd_write_smi_4(sc, SMI_EN, ichwd_read_smi_4(sc, SMI_EN) | SMI_TCO_EN); + uint32_t val; + + val = ichwd_read_smi_4(sc, SMI_EN); + + /* check if both TCO SMI and global SMI are already enabled */ + if ((val & (SMI_TCO_EN | SMI_GBL_EN)) == (SMI_TCO_EN | SMI_GBL_EN)) + return; + + /* try to enable TCO SMI and global SMI if permitted */ + val |= SMI_TCO_EN; + if (use_global_smi) + val |= SMI_GBL_EN; + + /* bail out if SMI is globally disabled and user doesn't allow to change that */ + if ((val & SMI_GBL_EN) == 0) { + printf("could not enable TCO SMI because SMI is globally disabled\n"); + return; + } + ichwd_write_smi_4(sc, SMI_EN, val); + + /* check if we succeeded */ + val = ichwd_read_smi_4(sc, SMI_EN); + if ((val & (SMI_TCO_EN | SMI_GBL_EN)) != (SMI_TCO_EN | SMI_GBL_EN)) + printf("could not enable SMIs, bits might be locked by BIOS\n"); } +/* + * Reset the watchdog status bits. + */ static __inline void ichwd_sts_reset(struct ichwd_softc *sc) { + /* + * The watchdog status bits are set to 1 by the hardware to + * indicate various conditions. They can be cleared by software + * by writing a 1, not a 0. + */ ichwd_write_tco_2(sc, TCO1_STS, TCO_TIMEOUT); + /* + * XXX The datasheet says that TCO_SECOND_TO_STS must be cleared + * before TCO_BOOT_STS, not the other way around. + */ ichwd_write_tco_2(sc, TCO2_STS, TCO_BOOT_STS); ichwd_write_tco_2(sc, TCO2_STS, TCO_SECOND_TO_STS); } +/* + * Enable the watchdog timer by clearing the TCO_TMR_HALT bit in the + * TCO1_CNT register. This is complicated by the need to preserve bit 9 + * of that same register, and the requirement that all other bits must be + * written back as zero. + */ static __inline void ichwd_tmr_enable(struct ichwd_softc *sc) { @@ -172,6 +263,9 @@ ichwd_tmr_enable(struct ichwd_softc *sc) ichwd_verbose_printf(sc->device, "timer enabled\n"); } +/* + * Disable the watchdog timer. See above for details. + */ static __inline void ichwd_tmr_disable(struct ichwd_softc *sc) { @@ -183,6 +277,11 @@ ichwd_tmr_disable(struct ichwd_softc *sc) ichwd_verbose_printf(sc->device, "timer disabled\n"); } +/* + * Reload the watchdog timer: writing anything to any of the lower five + * bits of the TCO_RLD register reloads the timer from the last value + * written to TCO_TMR. + */ static __inline void ichwd_tmr_reload(struct ichwd_softc *sc) { @@ -194,6 +293,10 @@ ichwd_tmr_reload(struct ichwd_softc *sc) ichwd_verbose_printf(sc->device, "timer reloaded\n"); } +/* + * Set the initial timeout value. Note that this must always be followed + * by a reload. + */ static __inline void ichwd_tmr_set(struct ichwd_softc *sc, unsigned int timeout) { @@ -220,8 +323,8 @@ ichwd_tmr_set(struct ichwd_softc *sc, unsigned int timeout) uint16_t tmr_val16 = ichwd_read_tco_2(sc, TCO_TMR2); tmr_val16 &= 0xfc00; - if (timeout > 0x0bff) - timeout = 0x0bff; + if (timeout > 0x03ff) + timeout = 0x03ff; tmr_val16 |= timeout; ichwd_write_tco_2(sc, TCO_TMR2, tmr_val16); } @@ -262,7 +365,8 @@ ichwd_clear_noreboot(struct ichwd_softc *sc) } /* - * Watchdog event handler. + * Watchdog event handler - called by the framework to enable or disable + * the watchdog or change the initial timeout value. */ static void ichwd_event(void *arg, unsigned int cmd, int *error) @@ -426,6 +530,13 @@ ichwd_attach(device_t dev) device_printf(dev, "%s (ICH%d or equivalent)\n", device_get_desc(dev), sc->ich_version); + /* + * XXX we should check the status registers (specifically, the + * TCO_SECOND_TO_STS bit in the TCO2_STS register) to see if we + * just came back from a watchdog-induced reset, and let the user + * know. + */ + /* reset the watchdog status registers */ ichwd_sts_reset(sc); @@ -435,8 +546,8 @@ ichwd_attach(device_t dev) /* register the watchdog event handler */ sc->ev_tag = EVENTHANDLER_REGISTER(watchdog_list, ichwd_event, sc, 0); - /* enable watchdog timeout interrupts */ - ichwd_intr_enable(sc); + /* disable the SMI handler */ + ichwd_smi_disable(sc); return (0); fail: @@ -466,8 +577,8 @@ ichwd_detach(device_t dev) if (sc->active) ichwd_tmr_disable(sc); - /* disable watchdog timeout interrupts */ - ichwd_intr_disable(sc); + /* enable the SMI handler */ + ichwd_smi_enable(sc); /* deregister event handler */ if (sc->ev_tag != NULL) diff --git a/sys/dev/ichwd/ichwd.h b/sys/dev/ichwd/ichwd.h index 51ed26d..8e2bdba 100644 --- a/sys/dev/ichwd/ichwd.h +++ b/sys/dev/ichwd/ichwd.h @@ -131,9 +131,9 @@ struct ichwd_softc { #define TCO1_CNT 0x08 /* TCO Control 1 */ #define TCO2_CNT 0x08 /* TCO Control 2 */ -/* bit definitions for SMI_EN and SMI_STS */ +/* SMI-related bit definitions */ +#define SMI_GBL_EN 0x0001 #define SMI_TCO_EN 0x2000 -#define SMI_TCO_STS 0x2000 /* timer value mask for TCO_RLD and TCO_TMR */ #define TCO_TIMER_MASK 0x1f -------------- next part -------------- diff --git a/sys/dev/ichwd/ichwd.c b/sys/dev/ichwd/ichwd.c index 71662a5..a4387a2 100644 --- a/sys/dev/ichwd/ichwd.c +++ b/sys/dev/ichwd/ichwd.c @@ -62,6 +62,7 @@ __FBSDID("$FreeBSD$"); #include #include #include +#include #include #include #include @@ -72,6 +73,14 @@ __FBSDID("$FreeBSD$"); #include + +static int use_global_smi = 0; + +SYSCTL_NODE(_hw, OID_AUTO, ichwd, CTLFLAG_RD, 0, "ichwd driver global parameters"); +TUNABLE_INT("hw.ichwd.use_global_smi", &use_global_smi); +SYSCTL_INT(_hw_ichwd, OID_AUTO, use_global_smi, CTLFLAG_RDTUN, &use_global_smi, 0, + "ichwd may try to change global SMI Enable bit if TCO SMI bit is locked"); + static struct ichwd_device ichwd_devices[] = { { DEVICEID_82801AA, "Intel 82801AA watchdog timer", 1 }, { DEVICEID_82801AB, "Intel 82801AB watchdog timer", 1 }, @@ -152,7 +161,37 @@ static devclass_t ichwd_devclass; static __inline void ichwd_smi_disable(struct ichwd_softc *sc) { - ichwd_write_smi_4(sc, SMI_EN, ichwd_read_smi_4(sc, SMI_EN) & ~SMI_TCO_EN); + uint32_t val; + + val = ichwd_read_smi_4(sc, SMI_EN); + + /* check if either TCO SMI is disabled or SMI is disabled globally */ + if ((val & (SMI_TCO_EN | SMI_GBL_EN)) != (SMI_TCO_EN | SMI_GBL_EN)) + return; + /* first try to disabled TCO SMI */ + val &= ~SMI_TCO_EN; + ichwd_write_smi_4(sc, SMI_EN, val); + + /* check if TCO SMI got disabled */ + val = ichwd_read_smi_4(sc, SMI_EN); + if ((val & SMI_TCO_EN) == 0) + return; + printf("could not disable TCO SMI, bit might be locked by BIOS\n"); + + /* check if user allowed to fiddle with global SMI settings */ + if (!use_global_smi) + return; + + /* try to disable SMI globally */ + val &= ~SMI_GBL_EN; + ichwd_write_smi_4(sc, SMI_EN, val); + + /* check results */ + val = ichwd_read_smi_4(sc, SMI_EN); + if (val & SMI_GBL_EN) + printf("could not disable SMI globally, bit might be locked by BIOS\n"); + else + printf("disabled SMI globally (permitted by use_global_smi tunable)\n"); } /* @@ -161,7 +200,30 @@ ichwd_smi_disable(struct ichwd_softc *sc) static __inline void ichwd_smi_enable(struct ichwd_softc *sc) { - ichwd_write_smi_4(sc, SMI_EN, ichwd_read_smi_4(sc, SMI_EN) | SMI_TCO_EN); + uint32_t val; + + val = ichwd_read_smi_4(sc, SMI_EN); + + /* check if both TCO SMI and global SMI are already enabled */ + if ((val & (SMI_TCO_EN | SMI_GBL_EN)) == (SMI_TCO_EN | SMI_GBL_EN)) + return; + + /* try to enable TCO SMI and global SMI if permitted */ + val |= SMI_TCO_EN; + if (use_global_smi) + val |= SMI_GBL_EN; + + /* bail out if SMI is globally disabled and user doesn't allow to change that */ + if ((val & SMI_GBL_EN) == 0) { + printf("could not enable TCO SMI because SMI is globally disabled\n"); + return; + } + ichwd_write_smi_4(sc, SMI_EN, val); + + /* check if we succeeded */ + val = ichwd_read_smi_4(sc, SMI_EN); + if ((val & (SMI_TCO_EN | SMI_GBL_EN)) != (SMI_TCO_EN | SMI_GBL_EN)) + printf("could not enable SMIs, bits might be locked by BIOS\n"); } /* diff --git a/sys/dev/ichwd/ichwd.h b/sys/dev/ichwd/ichwd.h index 51ed26d..8e2bdba 100644 --- a/sys/dev/ichwd/ichwd.h +++ b/sys/dev/ichwd/ichwd.h @@ -131,9 +131,9 @@ struct ichwd_softc { #define TCO1_CNT 0x08 /* TCO Control 1 */ #define TCO2_CNT 0x08 /* TCO Control 2 */ -/* bit definitions for SMI_EN and SMI_STS */ +/* SMI-related bit definitions */ +#define SMI_GBL_EN 0x0001 #define SMI_TCO_EN 0x2000 -#define SMI_TCO_STS 0x2000 /* timer value mask for TCO_RLD and TCO_TMR */ #define TCO_TIMER_MASK 0x1f From avg at freebsd.org Mon Apr 6 07:30:24 2009 From: avg at freebsd.org (Andriy Gapon) Date: Mon Apr 6 07:30:30 2009 Subject: ichwd: option to globally disable SMI In-Reply-To: <49DA1173.1080606@icyb.net.ua> References: <49DA1173.1080606@icyb.net.ua> Message-ID: <49DA11FB.7020805@freebsd.org> Forgot to mention: stable/7 version includes changes from head that des@ has recently made. -- Andriy Gapon From kwhite at site.uottawa.ca Mon Apr 6 07:21:24 2009 From: kwhite at site.uottawa.ca (Keith White) Date: Mon Apr 6 08:29:16 2009 Subject: Unable to associate using NDIS driver to WPA/WPA2 APs post 2009/03/26 Message-ID: <20090406092653.W48458@admin16.site.uottawa.ca> The platform is an msi wind U100 using an NDIS driver for the onboard rt2860. This has worked well, both at home with WPA2-PSK and at work with WPA2-EAP, until recently [post 2009/03/26?]. It stopped working with the recent changes to if_ndis and net80211. My current workaround is to use older versions of wlan.ko and if_ndis.ko, but that's not going to continue forever... ident differences between working and current versions: === if_ndis === 1 $FreeBSD: src/sys/dev/if_ndis/if_ndis.c,v 1.154 2009/03/24 04:20:17 weongyo Exp $ 1 $FreeBSD: src/sys/dev/if_ndis/if_ndis.c,v 1.155 2009/03/29 17:59:14 sam Exp $ === wlan.ko === 1 $FreeBSD: src/sys/net80211/ieee80211.c,v 1.68 2009/03/24 20:39:08 sam Exp $ 1 $FreeBSD: src/sys/net80211/ieee80211.c,v 1.70 2009/03/29 21:17:08 sam Exp $ 1 $FreeBSD: src/sys/net80211/ieee80211_ddb.c,v 1.23 2009/02/27 14:12:05 bz Exp $ 1 $FreeBSD: src/sys/net80211/ieee80211_ddb.c,v 1.24 2009/03/29 17:59:14 sam Exp $ 1 $FreeBSD: src/sys/net80211/ieee80211_freebsd.c,v 1.25 2009/01/08 17:12:47 sam Exp $ 1 $FreeBSD: src/sys/net80211/ieee80211_freebsd.c,v 1.27 2009/03/30 21:53:27 sam Exp $ 1 $FreeBSD: src/sys/net80211/ieee80211_hostap.c,v 1.15 2009/03/24 20:39:08 sam Exp $ 1 $FreeBSD: src/sys/net80211/ieee80211_hostap.c,v 1.16 2009/03/30 21:53:27 sam Exp $ 1 $FreeBSD: src/sys/net80211/ieee80211_ioctl.c,v 1.83 2009/03/24 20:39:08 sam Exp $ 1 $FreeBSD: src/sys/net80211/ieee80211_ioctl.c,v 1.84 2009/03/29 21:17:08 sam Exp $ 1 $FreeBSD: src/sys/net80211/ieee80211_node.c,v 1.123 2009/03/24 20:39:08 sam Exp $ 1 $FreeBSD: src/sys/net80211/ieee80211_node.c,v 1.125 2009/03/30 21:53:27 sam Exp $ 1 $FreeBSD: src/sys/net80211/ieee80211_output.c,v 1.79 2009/03/26 19:13:11 sam Exp $ 1 $FreeBSD: src/sys/net80211/ieee80211_output.c,v 1.82 2009/04/03 20:46:32 sam Exp $ 1 $FreeBSD: src/sys/net80211/ieee80211_scan.c,v 1.13 2009/02/22 18:46:36 sam Exp $ 1 $FreeBSD: src/sys/net80211/ieee80211_scan.c,v 1.14 2009/03/29 21:17:08 sam Exp $ 1 $FreeBSD: src/sys/net80211/ieee80211_sta.c,v 1.14 2009/03/25 03:02:03 sam Exp $ 1 $FreeBSD: src/sys/net80211/ieee80211_sta.c,v 1.15 2009/03/30 21:53:27 sam Exp $ 1 $FreeBSD: src/sys/net80211/ieee80211_wds.c,v 1.7 2009/03/24 20:39:08 sam Exp $ 1 $FreeBSD: src/sys/net80211/ieee80211_wds.c,v 1.8 2009/04/03 18:00:19 sam Exp $ === config === cpu I686_CPU ident "U100" options SCHED_ULE # ULE scheduler options PREEMPTION # Enable kernel thread preemption options INET # InterNETworking options INET6 # IPv6 communications protocols options SCTP # Stream Control Transmission Protocol options FFS # Berkeley Fast Filesystem options SOFTUPDATES # Enable FFS soft updates support options UFS_DIRHASH # Improve performance on big directories options UFS_GJOURNAL # Enable gjournal-based UFS journaling options MD_ROOT # MD is a potential root device options GEOM_PART_GPT # GUID Partition Tables. options GEOM_LABEL # Provides labelization options COMPAT_43TTY # BSD 4.3 TTY compat (sgtty) options COMPAT_FREEBSD4 # Compatible with FreeBSD4 options COMPAT_FREEBSD5 # Compatible with FreeBSD5 options COMPAT_FREEBSD6 # Compatible with FreeBSD6 options COMPAT_FREEBSD7 # Compatible with FreeBSD7 options SCSI_DELAY=5000 # Delay (in ms) before probing SCSI options KTRACE # ktrace(1) support options STACK # stack(9) 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 STOP_NMI # Stop CPUS using NMI instead of IPI options HWPMC_HOOKS # Necessary kernel hooks for hwpmc(4) #options KDTRACE_HOOKS # Kernel DTrace hooks #options DDB_CTF # for DTrace # To make an SMP kernel, the next two lines are needed options SMP # Symmetric MultiProcessor Kernel device apic # I/O APIC # CPU frequency control device cpufreq # Bus support. device acpi device pci # ATA and ATAPI devices device ata device atadisk # ATA disk drives options ATA_STATIC_ID # Static device numbering # SCSI peripherals device scbus # SCSI bus (required for SCSI) device ch # SCSI media changers device da # Direct Access (disks) device sa # Sequential Access (tape etc) device cd # CD device pass # Passthrough device (direct SCSI access) device ses # SCSI Environmental Services (and SAF-TE) # atkbdc0 controls both the keyboard and the PS/2 mouse device atkbdc # AT keyboard controller device atkbd # AT keyboard device psm # PS/2 mouse device vga # VGA video card driver device splash # Splash screen and screen saver support # syscons is the default console driver, resembling an SCO console device sc device agp # support several AGP chipsets # Add suspend/resume support for the i8254. device pmtimer # Pseudo devices. device loop # Network loopback device random # Entropy device device ether # Ethernet support device tun # Packet tunnel. device pty # BSD-style compatibility pseudo ttys device md # Memory "disks" device gif # IPv6 and IPv4 tunneling device faith # IPv6-to-IPv4 relaying (translation) device firmware # firmware assist module # The `bpf' device enables the Berkeley Packet Filter. # Be aware of the administrative consequences of enabling this! # Note that 'bpf' is required for DHCP. device bpf # Berkeley packet filter === dmesg === Copyright (c) 1992-2009 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 is a registered trademark of The FreeBSD Foundation. FreeBSD 8.0-CURRENT #6: Sun Apr 5 17:44:36 UTC 2009 root@demo:/usr/src/obj/usr/src/sys/U100 Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel(R) Atom(TM) CPU N270 @ 1.60GHz (1600.01-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x106c2 Stepping = 2 Features=0xbfe9fbff Features2=0x40c39d> AMD Features=0x100000 AMD Features2=0x1 TSC: P-state invariant Logical CPUs per core: 2 real memory = 1062936576 (1013 MB) avail memory = 1026977792 (979 MB) ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs cpu0 (BSP): APIC ID: 0 cpu1 (AP/HT): APIC ID: 1 ioapic0 irqs 0-23 on motherboard no match for ZwWriteFile no match for ZwCreateFile no match for ZwReadFile cryptosoft0: on motherboard acpi0: on motherboard acpi0: [ITHREAD] acpi0: Power Button (fixed) ACPI Error (evregion-0427): No handler for Region [EC__] (0xc4227740) [EmbeddedControl] [20070320] ACPI Error (exfldio-0390): Region EmbeddedControl(3) has no handler [20070320] ACPI Error (psparse-0626): Method parse/execution failed [\\_SB_.PCI0.SBRG.EC__.BAT1._STA] (Node 0xc4228260), AE_NOT_EXIST ACPI Error (uteval-0309): Method execution failed [\\_SB_.PCI0.SBRG.EC__.BAT1._STA] (Node 0xc4228260), AE_NOT_EXIST ACPI Error (evregion-0427): No handler for Region [EC__] (0xc4227740) [EmbeddedControl] [20070320] ACPI Error (exfldio-0390): Region EmbeddedControl(3) has no handler [20070320] ACPI Error (psparse-0626): Method parse/execution failed [\\_SB_.PCI0.SBRG.EC__.BAT1._STA] (Node 0xc4228260), AE_NOT_EXIST ACPI Error (uteval-0309): Method execution failed [\\_SB_.PCI0.SBRG.EC__.BAT1._STA] (Node 0xc4228260), AE_NOT_EXIST ACPI Error (evregion-0427): No handler for Region [EC__] (0xc4227740) [EmbeddedControl] [20070320] ACPI Error (exfldio-0390): Region EmbeddedControl(3) has no handler [20070320] ACPI Error (psparse-0626): Method parse/execution failed [\\_SB_.PCI0.SBRG.EC__.BAT1._STA] (Node 0xc4228260), AE_NOT_EXIST ACPI Error (uteval-0309): Method execution failed [\\_SB_.PCI0.SBRG.EC__.BAT1._STA] (Node 0xc4228260), AE_NOT_EXIST ACPI Error (evregion-0427): No handler for Region [EC__] (0xc4227740) [EmbeddedControl] [20070320] ACPI Error (exfldio-0390): Region EmbeddedControl(3) has no handler [20070320] ACPI Error (psparse-0626): Method parse/execution failed [\\_SB_.PCI0.SBRG.EC__.BAT1._STA] (Node 0xc4228260), AE_NOT_EXIST ACPI Error (uteval-0309): Method execution failed [\\_SB_.PCI0.SBRG.EC__.BAT1._STA] (Node 0xc4228260), AE_NOT_EXIST ACPI Error (evregion-0427): No handler for Region [EC__] (0xc4227740) [EmbeddedControl] [20070320] ACPI Error (exfldio-0390): Region EmbeddedControl(3) has no handler [20070320] ACPI Error (psparse-0626): Method parse/execution failed [\\_SB_.PCI0.SBRG.EC__.BAT1._STA] (Node 0xc4228260), AE_NOT_EXIST ACPI Error (uteval-0309): Method execution failed [\\_SB_.PCI0.SBRG.EC__.BAT1._STA] (Node 0xc4228260), AE_NOT_EXIST ACPI Error (evregion-0427): No handler for Region [EC__] (0xc4227740) [EmbeddedControl] [20070320] ACPI Error (exfldio-0390): Region EmbeddedControl(3) has no handler [20070320] ACPI Error (psparse-0626): Method parse/execution failed [\\_SB_.PCI0.SBRG.EC__.BAT1._STA] (Node 0xc4228260), AE_NOT_EXIST ACPI Error (uteval-0309): Method execution failed [\\_SB_.PCI0.SBRG.EC__.BAT1._STA] (Node 0xc4228260), AE_NOT_EXIST ACPI Error (evregion-0427): No handler for Region [EC__] (0xc4227740) [EmbeddedControl] [20070320] ACPI Error (exfldio-0390): Region EmbeddedControl(3) has no handler [20070320] ACPI Error (psparse-0626): Method parse/execution failed [\\_SB_.PCI0.SBRG.EC__.BAT1._STA] (Node 0xc4228260), AE_NOT_EXIST ACPI Error (uteval-0309): Method execution failed [\\_SB_.PCI0.SBRG.EC__.BAT1._STA] (Node 0xc4228260), AE_NOT_EXIST Timecounter "ACPI-safe" frequency 3579545 Hz quality 850 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x408-0x40b on acpi0 acpi_ec0: port 0x62,0x66 on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 vgapci0: port 0xe100-0xe107 mem 0xdfe80000-0xdfefffff,0xc0000000-0xcfffffff,0xdff00000-0xdff3ffff irq 16 at device 2.0 on pci0 agp0: on vgapci0 agp0: detected 7932k stolen memory agp0: aperture size is 256M acpi_video0: on vgapci0 vgapci1: mem 0xdfe00000-0xdfe7ffff at device 2.1 on pci0 hdac0: mem 0xffe00000-0xffe03fff irq 16 at device 27.0 on pci0 hdac0: HDA Driver Revision: 20090401_0132 hdac0: [ITHREAD] pcib1: irq 16 at device 28.0 on pci0 pci1: on pcib1 pci1: at device 0.0 (no driver attached) pcib2: irq 17 at device 28.1 on pci0 pci2: on pcib2 ndis0: <802.11n Wireless LAN Card> mem 0xdfc00000-0xdfc0ffff irq 17 at device 0.0 on pci2 ndis0: [ITHREAD] ndis0: NDIS API version: 5.0 NDIS: could not find file rate.bin in linker list NDIS: and no filesystems mounted yet, aborting NdisOpenFile() uhci0: port 0xe0a0-0xe0bf irq 23 at device 29.0 on pci0 uhci0: [ITHREAD] uhci0: LegSup = 0x1f30 usbus0: on uhci0 uhci1: port 0xe080-0xe09f irq 19 at device 29.1 on pci0 uhci1: [ITHREAD] uhci1: LegSup = 0x0f30 usbus1: on uhci1 uhci2: port 0xe060-0xe07f irq 18 at device 29.2 on pci0 uhci2: [ITHREAD] uhci2: LegSup = 0x0f30 usbus2: on uhci2 uhci3: port 0xe040-0xe05f irq 16 at device 29.3 on pci0 uhci3: [ITHREAD] uhci3: LegSup = 0x0f30 usbus3: on uhci3 ehci0: mem 0xdff40400-0xdff407ff irq 23 at device 29.7 on pci0 ehci0: [ITHREAD] usbus4: EHCI version 1.0 usbus4: on ehci0 pcib3: at device 30.0 on pci0 pci3: on pcib3 isab0: at device 31.0 on pci0 isa0: on isab0 atapci0: port 0xe0f0-0xe0f7,0xe0e0-0xe0e3,0xe0d0-0xe0d7,0xe0c0-0xe0c3,0xe020-0xe02f mem 0xdff40000-0xdff403ff irq 19 at device 31.2 on pci0 atapci0: [ITHREAD] atapci0: AHCI called from vendor specific driver atapci0: AHCI Version 01.10 controller with 4 ports PM not supported ata2: on atapci0 ata2: [ITHREAD] ata3: on atapci0 ata3: [ITHREAD] pci0: at device 31.3 (no driver attached) acpi_button0: on acpi0 acpi_button1: on acpi0 acpi_tz0: on acpi0 acpi_hpet0: iomem 0xfed03000-0xfed033ff on acpi0 Timecounter "HPET" frequency 14318180 Hz quality 900 atrtc0: port 0x70-0x71 irq 8 on acpi0 atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] atkbd0: [ITHREAD] psm0: irq 12 on atkbdc0 psm0: [GIANT-LOCKED] psm0: [ITHREAD] psm0: model IntelliMouse Explorer, device ID 4 acpi_acad0: on acpi0 battery0: on acpi0 acpi_lid0: on acpi0 cpu0: on acpi0 est0: on cpu0 p4tcc0: on cpu0 cpu1: on acpi0 est1: on cpu1 p4tcc1: on cpu1 pmtimer0 on isa0 orm0: at iomem 0xcf000-0xcffff pnpid ORM0000 on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 ata0 at port 0x1f0-0x1f7,0x3f6 irq 14 on isa0 ata0: [ITHREAD] ata1 at port 0x170-0x177,0x376 irq 15 on isa0 ata1: [ITHREAD] Timecounters tick every 10.000 msec ipfw2 (+ipv6) initialized, divert loadable, nat loadable, rule-based forwarding disabled, default to deny, logging disabled usbus0: 12Mbps Full Speed USB v1.0 usbus1: 12Mbps Full Speed USB v1.0 usbus2: 12Mbps Full Speed USB v1.0 usbus3: 12Mbps Full Speed USB v1.0 usbus4: 480Mbps High Speed USB v2.0 ad4: 152627MB at ata2-master SATA150 hdac0: HDA Codec #0: Realtek ALC888 pcm0: at cad 0 nid 1 on hdac0 SMP: AP CPU #1 Launched! ugen0.1: at usbus0 uhub0: on usbus0 ugen2.1: at usbus2 uhub1: on usbus2 ugen3.1: at usbus3 uhub2: on usbus3 ugen1.1: at usbus1 uhub3: on usbus1 ugen4.1: at usbus4 uhub4: on usbus4 GEOM_LABEL: Label for provider ad4s1 is msdosfs/WINRE. uhub0: 2 ports with 2 removable, self powered uhub1: 2 ports with 2 removable, self powered uhub3: 2 ports with 2 removable, self powered uhub2: 2 ports with 2 removable, self powered GEOM_LABEL: Label for provider ad4s2 is ntfs/OS_Install. GEOM_LABEL: Label for provider ad4s4 is ufsid/49d7d542f62efef2. GEOM_LABEL: Label for provider ad4s4 is ufs/Source. Root mount waiting for: usbus4 Root mount waiting for: usbus4 Root mount waiting for: usbus4 Root mount waiting for: usbus4 uhub4: 8 ports with 8 removable, self powered Root mount waiting for: usbus4 ugen4.2: at usbus4 Root mount waiting for: usbus4 ugen4.3: at usbus4 umass0: on usbus4 umass0: SCSI over Bulk-Only; quirks = 0x0000 Root mount waiting for: usbus4 umass0:0:0:-1: Attached to scbus0 Root mount waiting for: CAM usbus4 (probe0:umass-sim0:0:0:0): TEST UNIT READY. CDB: 0 0 0 0 0 0 (probe0:umass-sim0:0:0:0): CAM Status: SCSI Status Error (probe0:umass-sim0:0:0:0): SCSI Status: Check Condition (probe0:umass-sim0:0:0:0): UNIT ATTENTION asc:28,0 (probe0:umass-sim0:0:0:0): Not ready to ready change, medium may have changed (probe0:umass-sim0:0:0:0): Retrying Command (per Sense Data) da0 at umass-sim0 bus 0 target 0 lun 0 da0: Removable Direct Access SCSI-0 device da0: 40.000MB/s transfers da0: 990MB (2029056 512 byte sectors: 64H 32S/T 990C) GEOM_LABEL: Label for provider da0s1 is label/Thumb. GEOM_LABEL: Label for provider da0s1 is msdosfs/THUMB. Enter passphrase for da0s3: ugen3.2: at usbus3 ******** GEOM_ELI: Device da0s3.eli created. GEOM_ELI: Encryption: Blowfish-CBC 128 GEOM_ELI: Crypto: software GEOM_LABEL: Label for provider da0s2a is ufsid/49cbe7372542dd60. GEOM_LABEL: Label for provider da0s2a is ufs/dotRoot. da0s3.eli.uzip: 31627 x 32768 blocks GEOM: da0s3.eli.uzip: media size does not match label. GEOM_LABEL: Label for provider da0s3.eli.uzipa is ufsid/49d826e6cbc92b93. GEOM_LABEL: Label for provider da0s3.eli.uzipa is ufs/FreeBSDonUSB. Trying to mount root from ufs:ufs/FreeBSDonUSB GEOM_LABEL: Label for provider md0 is ufsid/49d9fb847ed4f656. GEOM_LABEL: Label ufsid/49d9fb847ed4f656 removed. wlan0: Ethernet address: 00:1d:92:cd:45:d0 NDIS: open file /compat/ndis/rate.bin failed: 2 GEOM_LABEL: Label for provider md1 is ufsid/49d9fba8f0ad448d. === ...keith -- Keith White, EITI/SITE, University of Ottawa kwhite@site.uottawa.ca [+1 613 562 5800 x6681] FAX [+1 613 562 5664] From onemda at gmail.com Mon Apr 6 08:32:45 2009 From: onemda at gmail.com (Paul B. Mahol) Date: Mon Apr 6 08:32:52 2009 Subject: Unable to associate using NDIS driver to WPA/WPA2 APs post 2009/03/26 In-Reply-To: <20090406092653.W48458@admin16.site.uottawa.ca> References: <20090406092653.W48458@admin16.site.uottawa.ca> Message-ID: <3a142e750904060832r41febee3k1dd6e4f5d7bc0f22@mail.gmail.com> On 4/6/09, Keith White wrote: > The platform is an msi wind U100 using an NDIS driver for the onboard > rt2860. > > This has worked well, both at home with WPA2-PSK and at work with > WPA2-EAP, until recently [post 2009/03/26?]. It stopped working > with the recent changes to if_ndis and net80211. > > My current workaround is to use older versions of wlan.ko and > if_ndis.ko, but that's not going to continue forever... Known issue, I'm slowly working on it ... any help is appreicated -- Paul From michael.copeland at gmail.com Mon Apr 6 08:45:49 2009 From: michael.copeland at gmail.com (michael) Date: Mon Apr 6 08:46:01 2009 Subject: Unable to associate using NDIS driver to WPA/WPA2 APs post 2009/03/26 In-Reply-To: <3a142e750904060832r41febee3k1dd6e4f5d7bc0f22@mail.gmail.com> References: <20090406092653.W48458@admin16.site.uottawa.ca> <3a142e750904060832r41febee3k1dd6e4f5d7bc0f22@mail.gmail.com> Message-ID: <49DA23A9.50707@gmail.com> Paul B. Mahol wrote: > On 4/6/09, Keith White wrote: > >> The platform is an msi wind U100 using an NDIS driver for the onboard >> rt2860. >> >> This has worked well, both at home with WPA2-PSK and at work with >> WPA2-EAP, until recently [post 2009/03/26?]. It stopped working >> with the recent changes to if_ndis and net80211. >> >> My current workaround is to use older versions of wlan.ko and >> if_ndis.ko, but that's not going to continue forever... >> > > Known issue, I'm slowly working on it ... any help is appreicated > > > ndis is causing my machine to panic with rt2870 and rt2860 devices. specifically, it was causing a panic the moment rt2870_sys.ko was loaded, however, if ndis.ko was loaded first, it would take up to a minute. From babkin at verizon.net Mon Apr 6 08:35:42 2009 From: babkin at verizon.net (Sergey Babkin) Date: Mon Apr 6 08:50:52 2009 Subject: Improving the kernel/i386 timecounter performance (GSoC proposal) Message-ID: <13591482.311321.1239032116786.JavaMail.root@vms068.mailsrvcs.net> Apr 4, 2009 02:02:07 PM, julian@elischer.org wrote: >Hey Sergey, whatever you are using for a mail client SUCKS >real bad at the moment.. > > it's really messing up your outgoing mails.. > >note the mail below.... Looks like using the text mode didn't help :-( Oh, well, I guess I should not write replies from the web interface. -SB From phk at phk.freebsd.dk Mon Apr 6 09:04:47 2009 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Mon Apr 6 09:05:04 2009 Subject: ichwd: option to globally disable SMI In-Reply-To: Your message of "Mon, 06 Apr 2009 17:28:03 +0300." <49DA1173.1080606@icyb.net.ua> Message-ID: <31158.1239033885@critter.freebsd.dk> In message <49DA1173.1080606@icyb.net.ua>, Andriy Gapon writes: >I am attaching a patch that makes ichwd check and report result of SMI bit >operations and also try to disable SMI globally if permitted by >hw.ichwd.use_global_smi tunable. Disabling SMI globally is incredibly ill-advised, for one thing it may cause your laptop to autowarnerize, but it can also ruin your batteries, prevent ACPI from working etc. Under no circumstances should FreeBSD attempt to disable SMI globally without explicit instruction from a knowledgeable and informed user. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From avg at icyb.net.ua Mon Apr 6 09:12:02 2009 From: avg at icyb.net.ua (Andriy Gapon) Date: Mon Apr 6 09:12:09 2009 Subject: ichwd: option to globally disable SMI In-Reply-To: <31158.1239033885@critter.freebsd.dk> References: <31158.1239033885@critter.freebsd.dk> Message-ID: <49DA29CE.3070801@icyb.net.ua> on 06/04/2009 19:04 Poul-Henning Kamp said the following: > In message <49DA1173.1080606@icyb.net.ua>, Andriy Gapon writes: > >> I am attaching a patch that makes ichwd check and report result of SMI bit >> operations and also try to disable SMI globally if permitted by >> hw.ichwd.use_global_smi tunable. > > Disabling SMI globally is incredibly ill-advised, for one thing it > may cause your laptop to autowarnerize, but it can also ruin your > batteries, prevent ACPI from working etc. > > Under no circumstances should FreeBSD attempt to disable SMI globally > without explicit instruction from a knowledgeable and informed user. > Well, this is a mistake on my part, I am using ichwd on a desktop and so I completely missed the fact that somebody might think of trying this on a laptop. Thank you for this prominent warning. In any case, a user has first to apply the patch, set hw.ichwd.use_global_smi tunable and the normal way of disabling TCO SMI should fail in order for global SMI disabling to be attempted. -- Andriy Gapon From kwhite at site.uottawa.ca Mon Apr 6 09:10:31 2009 From: kwhite at site.uottawa.ca (Keith White) Date: Mon Apr 6 09:41:15 2009 Subject: Unable to associate using NDIS driver to WPA/WPA2 APs post 2009/03/26 In-Reply-To: <3a142e750904060832r41febee3k1dd6e4f5d7bc0f22@mail.gmail.com> References: <20090406092653.W48458@admin16.site.uottawa.ca> <3a142e750904060832r41febee3k1dd6e4f5d7bc0f22@mail.gmail.com> Message-ID: <20090406120621.K51648@admin16.site.uottawa.ca> On Mon, 6 Apr 2009, Paul B. Mahol wrote: > On 4/6/09, Keith White wrote: >> The platform is an msi wind U100 using an NDIS driver for the onboard >> rt2860. >> >> This has worked well, both at home with WPA2-PSK and at work with >> WPA2-EAP, until recently [post 2009/03/26?]. It stopped working >> with the recent changes to if_ndis and net80211. >> >> My current workaround is to use older versions of wlan.ko and >> if_ndis.ko, but that's not going to continue forever... > > Known issue, I'm slowly working on it ... any help is appreicated Knowing "it's known" is a help to me! What help would you like? Unfortunately, the only help I can realistically provide is trying patches or running tests. ...keith -- Keith White, EITI/SITE, University of Ottawa kwhite@site.uottawa.ca [+1 613 562 5800 x6681] FAX [+1 613 562 5664] From jh at saunalahti.fi Mon Apr 6 10:00:42 2009 From: jh at saunalahti.fi (Jaakko Heinonen) Date: Mon Apr 6 10:00:50 2009 Subject: [patch] mount_nfs(8) option parsing bug Message-ID: <20090406170038.GA4058@a91-153-125-115.elisa-laajakaista.fi> Hi, mount_nfs(8) doesn't parse options specified with -o correctly if an option with value is preceded by an option without value. # mount_nfs -o rdirplus,acdirmax=0 localhost:/dir /mnt mount_nfs: /mnt, illegal acdirmax: : Invalid argument Possible fix: %%% Index: sbin/mount_nfs/mount_nfs.c =================================================================== --- sbin/mount_nfs/mount_nfs.c (revision 190637) +++ sbin/mount_nfs/mount_nfs.c (working copy) @@ -265,16 +265,16 @@ main(int argc, char *argv[]) char *pnextopt = NULL; char *val = ""; pass_flag_to_nmount = 1; - pval = strchr(opt, '='); pnextopt = strchr(opt, ','); - if (pval != NULL) { - *pval = '\0'; - val = pval + 1; - } if (pnextopt) { *pnextopt = '\0'; pnextopt++; } + pval = strchr(opt, '='); + if (pval != NULL) { + *pval = '\0'; + val = pval + 1; + } if (strcmp(opt, "bg") == 0) { opflags |= BGRND; pass_flag_to_nmount=0; %%% -- Jaakko From sam at freebsd.org Mon Apr 6 10:28:53 2009 From: sam at freebsd.org (Sam Leffler) Date: Mon Apr 6 10:29:00 2009 Subject: Unable to associate using NDIS driver to WPA/WPA2 APs post 2009/03/26 In-Reply-To: <20090406092653.W48458@admin16.site.uottawa.ca> References: <20090406092653.W48458@admin16.site.uottawa.ca> Message-ID: <49DA3BD4.4040900@freebsd.org> Keith White wrote: > The platform is an msi wind U100 using an NDIS driver for the onboard > rt2860. > > This has worked well, both at home with WPA2-PSK and at work with > WPA2-EAP, until recently [post 2009/03/26?]. It stopped working > with the recent changes to if_ndis and net80211. > > My current workaround is to use older versions of wlan.ko and > if_ndis.ko, but that's not going to continue forever... > r190579 broke ndis. Sam From mister.olli at googlemail.com Mon Apr 6 10:34:01 2009 From: mister.olli at googlemail.com (Mister Olli) Date: Mon Apr 6 10:34:08 2009 Subject: Compiling CURRENT with XEN config fails In-Reply-To: References: <1238162602.24399.29.camel@phoenix.blechhirn.net> <1238700894.14361.615.camel@phoenix.blechhirn.net> <1238774262.5533.4.camel@phoenix.blechhirn.net> <42C956C5-BBFD-4E0A-949D-DD71EF3E883A@rabson.org> <1238873676.2667.5.camel@phoenix.blechhirn.net> Message-ID: <1239039221.24515.8.camel@phoenix.blechhirn.net> Hi, thanks a lot for the hint. only doing 'make buildworld && make buildkernel' brings me to a working 8-CURRENT in PV mode. Even the nasty bug that it couldn't be build without 'NFSLOCKD' is included is fixed. Great work :-)) Regards, Olli On Sa, 2009-04-04 at 22:28 +0100, Doug Rabson wrote: > Just 'make buildworld' should be enough. This cleans, depends and > builds and also makes sure the right toolchain is used for the build. > > > On 4 Apr 2009, at 20:34, Mister Olli wrote: > > > Hi, > > > > do you also do a > > > > make cleandepend > > make clean > > make depend > > > > before building world? > > > > > > Regards, > > Olli > > > > > > On Sa, 2009-04-04 at 14:35 +0100, Doug Rabson wrote: > >> On 3 Apr 2009, at 16:57, Mister Olli wrote: > >> > >>> Hi, > >>> > >>> With revision 190627 (which is btw oder than the one in my test > >>> before) > >>> I get errors during 'make depend'. I can't even do a 'make > >>> buildworld'. > >>> > >>> ===> sbin/ifconfig (depend) > >>> rm -f .depend > >>> mkdep -f .depend -a ifconfig.c af_link.c af_inet.c af_inet6.c > >>> af_atalk.c ifclone.c ifmac.c ifmedia.c ifvlan.c ifgre.c > >>> ifieee80211.c regdomain.c ifcarp.c ifgroup.c ifpfsync.c ifbridge.c > >>> iflagg.c af_ipx.c > >>> ifieee80211.c:82:39: error: net80211/ieee80211_superg.h: No such > >>> file or directory > >>> mkdep: compile failed > >>> *** Error code 1 > >>> > >>> Stop in /usr/src/sbin/ifconfig. > >>> *** Error code 1 > >>> > >> > >> Thats odd. I just did a buildworld of revision 190687 without any > >> similar problems. Also, this particular file isn't one of the ones I > >> changed for Xen - its part of the wifi support which is completely > >> unrelated. > >> > > > From rnoland at FreeBSD.org Mon Apr 6 10:37:01 2009 From: rnoland at FreeBSD.org (Robert Noland) Date: Mon Apr 6 10:37:08 2009 Subject: ddb can't use USB keyboard? In-Reply-To: <49D99F42.5040104@delphij.net> References: <49D99F42.5040104@delphij.net> Message-ID: <1239039350.1852.1.camel@balrog.2hip.net> On Sun, 2009-04-05 at 23:20 -0700, Xin LI wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hi, > > Did anyone used USB keyboard in ddb? It looks like that once I entered > ddb, the keyboard would stop responding :( It also seems that you can't use ddb or get dumps if you boot from usb disk. robert. > Cheers, > - -- > Xin LI http://www.delphij.net/ > FreeBSD - The Power to Serve! > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2.0.11 (FreeBSD) > > iEYEARECAAYFAknZn0EACgkQi+vbBBjt66AT9gCfbPPQthQi1I7cP798cUdY5U9Q > 754AoJLYmTO8FZAR4JTzHK77vwj1glkc > =/3Wg > -----END PGP SIGNATURE----- > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" -- Robert Noland FreeBSD -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 196 bytes Desc: This is a digitally signed message part Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20090406/5d5e9379/attachment.pgp From gelraen.ua at gmail.com Mon Apr 6 10:54:49 2009 From: gelraen.ua at gmail.com (Maxim Ignatenko) Date: Mon Apr 6 10:56:28 2009 Subject: [patch] matching IPv4 broadcast packets in ipfw In-Reply-To: References: Message-ID: Strange, but packet TCP 88.222.53.231:55882 192.168.100.2:44943 out via gif0 matched the rule allow log ip from any to any broadcast ifconfig gif0 gif0: flags=8051 metric 0 mtu 1280 tunnel inet x.x.x.x --> x.x.x.x inet 192.168.100.1 --> 192.168.100.2 netmask 0xfffffffc I thougth it should not be matched because gif0 has not set IFF_BROADCAST in if_flags From ccuiyyan at gmail.com Mon Apr 6 11:10:26 2009 From: ccuiyyan at gmail.com (=?GB2312?B?tN7R0mNjdWl5eWFuQHNpbmEuY29t?=) Date: Mon Apr 6 11:41:37 2009 Subject: AMD Opteron CPU PMC patch Message-ID: <4451ccf20904061110m91da3del8d39d81132a4dc48@mail.gmail.com> Hi all : Are there any patches available in FreeBSD-current 8.0 for AMD Opteron CPU to support PMC? Best Wishes! Yan From ccuiyyan at gmail.com Mon Apr 6 11:56:07 2009 From: ccuiyyan at gmail.com (=?GB2312?B?tN7R0mNjdWl5eWFuQHNpbmEuY29t?=) Date: Mon Apr 6 12:10:40 2009 Subject: gprof kernel profiling Message-ID: <4451ccf20904061122n511765h2ea279d6edc4f702@mail.gmail.com> Dear All; gprof cannot work on my box. I configure the kernel with -p option; The whole kernel can be compiled and rebooted. However, the system cannot respond to anything when i using the command "kgmon -b". Any ideas? Best Wishes! Yan From onemda at gmail.com Mon Apr 6 13:44:52 2009 From: onemda at gmail.com (Paul B. Mahol) Date: Mon Apr 6 13:45:00 2009 Subject: Unable to associate using NDIS driver to WPA/WPA2 APs post 2009/03/26 In-Reply-To: <49DA23A9.50707@gmail.com> References: <20090406092653.W48458@admin16.site.uottawa.ca> <3a142e750904060832r41febee3k1dd6e4f5d7bc0f22@mail.gmail.com> <49DA23A9.50707@gmail.com> Message-ID: <3a142e750904061344k3c6f5f9aue1efbd16bef0e53a@mail.gmail.com> On 4/6/09, michael wrote: > > > Paul B. Mahol wrote: >> On 4/6/09, Keith White wrote: >> >>> The platform is an msi wind U100 using an NDIS driver for the onboard >>> rt2860. >>> >>> This has worked well, both at home with WPA2-PSK and at work with >>> WPA2-EAP, until recently [post 2009/03/26?]. It stopped working >>> with the recent changes to if_ndis and net80211. >>> >>> My current workaround is to use older versions of wlan.ko and >>> if_ndis.ko, but that's not going to continue forever... >>> >> >> Known issue, I'm slowly working on it ... any help is appreicated >> >> >> > ndis is causing my machine to panic with rt2870 and rt2860 devices. > specifically, it was causing a panic the moment rt2870_sys.ko was > loaded, however, if ndis.ko was loaded first, it would take up to a minute. amd64 or i386 8.CURRENT, do you have backtrace? -- Paul From onemda at gmail.com Mon Apr 6 13:59:18 2009 From: onemda at gmail.com (Paul B. Mahol) Date: Mon Apr 6 13:59:25 2009 Subject: ddb can't use USB keyboard? In-Reply-To: <1239039350.1852.1.camel@balrog.2hip.net> References: <49D99F42.5040104@delphij.net> <1239039350.1852.1.camel@balrog.2hip.net> Message-ID: <3a142e750904061359iea7fe97mc69825ddba10bf85@mail.gmail.com> On 4/6/09, Robert Noland wrote: > On Sun, 2009-04-05 at 23:20 -0700, Xin LI wrote: >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> Hi, >> >> Did anyone used USB keyboard in ddb? It looks like that once I entered >> ddb, the keyboard would stop responding :( > > It also seems that you can't use ddb or get dumps if you boot from usb > disk. Last time I checked it I could use ddb(4) from usb disk. -- Paul From trebestie at gmail.com Mon Apr 6 14:02:32 2009 From: trebestie at gmail.com (Diego Depaoli) Date: Mon Apr 6 14:02:39 2009 Subject: AMD 780G chipset major issues 1/3 (ata, ataati) Message-ID: <83e5fb980904061402x1b28b076kc13c375caba0e679@mail.gmail.com> Hi all, please compare these logs 1 -> without ataati #dmesg |grep ata atapci0: port 0xc000-0xc007,0xb000-0xb003,0xa000-0xa007,0x9000-0x9003,0x8000-0x800f mem 0xfe8ffc00-0xfe8fffff irq 22 at device 17.0 on pci0 atapci0: [ITHREAD] ata2: on atapci0 ata2: [ITHREAD] ata3: on atapci0 ata3: [ITHREAD] atapci1: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xff00-0xff0f at device 20.1 on pci0 ata0: on atapci1 ata0: [ITHREAD] ata1: on atapci1 ata1: [ITHREAD] acd0: DVDR at ata1-master UDMA33 ad4: 305245MB at ata2-master UDMA33 ad6: 305245MB at ata3-master UDMA33 my sata disks are udma33 2 -> with ataati loaded as module atapci0: port 0xc000-0xc007,0xb000-0xb003,0xa000-0xa007,0x9000-0x9003,0x8000-0x800f mem 0xfe8ffc00-0xfe8fffff irq 22 at device 17.0 on pci0 atapci0: [ITHREAD] atapci0: AHCI Version 01.10 controller with 4 ports PM supported ata2: on atapci0 ata2: port is not ready (timeout 0ms) tfd = 000001d0 ata2: software reset clear timeout ata2: [ITHREAD] ata3: on atapci0 ata3: port is not ready (timeout 0ms) tfd = 000001d0 ata3: software reset clear timeout ata3: [ITHREAD] ata4: on atapci0 ata4: [ITHREAD] ata5: on atapci0 ata5: [ITHREAD] atapci1: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xff00-0xff0f at device 20.1 on pci0 ata0: on atapci1 ata0: [ITHREAD] ad4: 305245MB at ata2-master SATA300 ad6: 305245MB at ata3-master SATA300 my sata disks are right, but ata1 and acd0 vanished -- Diego Depaoli From trebestie at gmail.com Mon Apr 6 14:02:45 2009 From: trebestie at gmail.com (Diego Depaoli) Date: Mon Apr 6 14:02:51 2009 Subject: AMD 780G chipset major issues 2/3 (snd_hda) Message-ID: <83e5fb980904061402t7e07e9e7v795a27cb588ac518@mail.gmail.com> After boot #dmesg | grep hda hdac0: mem 0xfeae8000-0xfeaebfff irq 19 at device 5.1 on pci1 hdac0: HDA Driver Revision: 20090401_0132 hdac0: [ITHREAD] hdac1: mem 0xfe8f4000-0xfe8f7fff irq 16 at device 20.2 on pci0 hdac1: HDA Driver Revision: 20090401_0132 hdac1: [ITHREAD] hdac0: HDA Codec #0: ATI RS690/780 HDMI pcm0: at cad 0 nid 1 on hdac0 hdac1: HDA Codec #0: Realtek ALC662 pcm1: at cad 0 nid 1 on hdac1 sound doesn't work #kldunload snd_hda #kldload snd_hda #dmesg | grep hda hdac0: detached hdac1: detached hdac0: mem 0xfe8f4000-0xfe8f7fff irq 16 at device 20.2 on pci0 hdac0: HDA Driver Revision: 20090401_0132 hdac0: [ITHREAD] hdac0: HDA Codec #0: Realtek ALC662 hdac1: mem 0xfeae8000-0xfeaebfff irq 19 at device 5.1 on pci1 hdac1: HDA Driver Revision: 20090401_0132 hdac1: [ITHREAD] hdac1: HDA Codec #0: ATI RS690/780 HDMI pcm0: at cad 0 nid 1 on hdac0 pcm1: at cad 0 nid 1 on hdac1 Now sound works -- Diego Depaoli From trebestie at gmail.com Mon Apr 6 14:02:56 2009 From: trebestie at gmail.com (Diego Depaoli) Date: Mon Apr 6 14:03:03 2009 Subject: AMD 780G chipset major issues 3/3 (btx) Message-ID: <83e5fb980904061402q73940f8at4ec4b8f821354320@mail.gmail.com> And finally... if I enable ahci in bios the system won't boot with btx halted. Ctrl+alt+del is the only allowed action. Yes... it's a low cost motherboard, but I'm a bit confused. Regards -- Diego Depaoli From onemda at gmail.com Mon Apr 6 14:06:39 2009 From: onemda at gmail.com (Paul B. Mahol) Date: Mon Apr 6 14:07:17 2009 Subject: AMD 780G chipset major issues 2/3 (snd_hda) In-Reply-To: <83e5fb980904061402t7e07e9e7v795a27cb588ac518@mail.gmail.com> References: <83e5fb980904061402t7e07e9e7v795a27cb588ac518@mail.gmail.com> Message-ID: <3a142e750904061406x307e31f2v562725525c3e0641@mail.gmail.com> On 4/6/09, Diego Depaoli wrote: > After boot > #dmesg | grep hda > hdac0: mem > 0xfeae8000-0xfeaebfff irq 19 at device 5.1 on pci1 > hdac0: HDA Driver Revision: 20090401_0132 > hdac0: [ITHREAD] > hdac1: mem > 0xfe8f4000-0xfe8f7fff irq 16 at device 20.2 on pci0 > hdac1: HDA Driver Revision: 20090401_0132 > hdac1: [ITHREAD] > hdac0: HDA Codec #0: ATI RS690/780 HDMI > pcm0: at cad 0 nid 1 on hdac0 > hdac1: HDA Codec #0: Realtek ALC662 > pcm1: at cad 0 nid 1 on hdac1 > > sound doesn't work > > #kldunload snd_hda > #kldload snd_hda > > #dmesg | grep hda > hdac0: detached > hdac1: detached > hdac0: mem > 0xfe8f4000-0xfe8f7fff irq 16 at device 20.2 on pci0 > hdac0: HDA Driver Revision: 20090401_0132 > hdac0: [ITHREAD] > hdac0: HDA Codec #0: Realtek ALC662 > hdac1: mem > 0xfeae8000-0xfeaebfff irq 19 at device 5.1 on pci1 > hdac1: HDA Driver Revision: 20090401_0132 > hdac1: [ITHREAD] > hdac1: HDA Codec #0: ATI RS690/780 HDMI > pcm0: at cad 0 nid 1 on hdac0 > pcm1: at cad 0 nid 1 on hdac1 > > Now sound works Because pcm0 switched position with pcm1 :-) -- Paul From rnoland at FreeBSD.org Mon Apr 6 14:06:43 2009 From: rnoland at FreeBSD.org (Robert Noland) Date: Mon Apr 6 14:07:18 2009 Subject: ddb can't use USB keyboard? In-Reply-To: <3a142e750904061359iea7fe97mc69825ddba10bf85@mail.gmail.com> References: <49D99F42.5040104@delphij.net> <1239039350.1852.1.camel@balrog.2hip.net> <3a142e750904061359iea7fe97mc69825ddba10bf85@mail.gmail.com> Message-ID: <1239051941.1868.1.camel@balrog.2hip.net> On Mon, 2009-04-06 at 22:59 +0200, Paul B. Mahol wrote: > On 4/6/09, Robert Noland wrote: > > On Sun, 2009-04-05 at 23:20 -0700, Xin LI wrote: > >> -----BEGIN PGP SIGNED MESSAGE----- > >> Hash: SHA1 > >> > >> Hi, > >> > >> Did anyone used USB keyboard in ddb? It looks like that once I entered > >> ddb, the keyboard would stop responding :( > > > > It also seems that you can't use ddb or get dumps if you boot from usb > > disk. > > Last time I checked it I could use ddb(4) from usb disk. hrm, ok... I'll panic again soon I'm sure, but I was getting something about can't do usb_polling. robert. -- Robert Noland FreeBSD -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 196 bytes Desc: This is a digitally signed message part Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20090406/75d2666b/attachment.pgp From onemda at gmail.com Mon Apr 6 14:07:23 2009 From: onemda at gmail.com (Paul B. Mahol) Date: Mon Apr 6 14:07:29 2009 Subject: ddb can't use USB keyboard? In-Reply-To: <1239051941.1868.1.camel@balrog.2hip.net> References: <49D99F42.5040104@delphij.net> <1239039350.1852.1.camel@balrog.2hip.net> <3a142e750904061359iea7fe97mc69825ddba10bf85@mail.gmail.com> <1239051941.1868.1.camel@balrog.2hip.net> Message-ID: <3a142e750904061407nc0d24ceme07edfaf4fb3c7a5@mail.gmail.com> On 4/6/09, Robert Noland wrote: > On Mon, 2009-04-06 at 22:59 +0200, Paul B. Mahol wrote: >> On 4/6/09, Robert Noland wrote: >> > On Sun, 2009-04-05 at 23:20 -0700, Xin LI wrote: >> >> -----BEGIN PGP SIGNED MESSAGE----- >> >> Hash: SHA1 >> >> >> >> Hi, >> >> >> >> Did anyone used USB keyboard in ddb? It looks like that once I entered >> >> ddb, the keyboard would stop responding :( >> > >> > It also seems that you can't use ddb or get dumps if you boot from usb >> > disk. >> >> Last time I checked it I could use ddb(4) from usb disk. > > hrm, ok... I'll panic again soon I'm sure, but I was getting something > about can't do usb_polling. usb keyboard? -- Paul From trebestie at gmail.com Mon Apr 6 14:17:03 2009 From: trebestie at gmail.com (Diego Depaoli) Date: Mon Apr 6 14:17:11 2009 Subject: AMD 780G chipset major issues 2/3 (snd_hda) In-Reply-To: <3a142e750904061406x307e31f2v562725525c3e0641@mail.gmail.com> References: <83e5fb980904061402t7e07e9e7v795a27cb588ac518@mail.gmail.com> <3a142e750904061406x307e31f2v562725525c3e0641@mail.gmail.com> Message-ID: <83e5fb980904061417p68d63c54t7ad96e06aefe32ba@mail.gmail.com> On Mon, Apr 6, 2009 at 11:06 PM, Paul B. Mahol wrote: > Because pcm0 switched position with pcm1 :-) Already noticed. Do you know why? -- Diego Depaoli From rnoland at FreeBSD.org Mon Apr 6 14:21:38 2009 From: rnoland at FreeBSD.org (Robert Noland) Date: Mon Apr 6 14:21:54 2009 Subject: ddb can't use USB keyboard? In-Reply-To: <3a142e750904061407nc0d24ceme07edfaf4fb3c7a5@mail.gmail.com> References: <49D99F42.5040104@delphij.net> <1239039350.1852.1.camel@balrog.2hip.net> <3a142e750904061359iea7fe97mc69825ddba10bf85@mail.gmail.com> <1239051941.1868.1.camel@balrog.2hip.net> <3a142e750904061407nc0d24ceme07edfaf4fb3c7a5@mail.gmail.com> Message-ID: <1239052841.1868.3.camel@balrog.2hip.net> On Mon, 2009-04-06 at 23:07 +0200, Paul B. Mahol wrote: > On 4/6/09, Robert Noland wrote: > > On Mon, 2009-04-06 at 22:59 +0200, Paul B. Mahol wrote: > >> On 4/6/09, Robert Noland wrote: > >> > On Sun, 2009-04-05 at 23:20 -0700, Xin LI wrote: > >> >> -----BEGIN PGP SIGNED MESSAGE----- > >> >> Hash: SHA1 > >> >> > >> >> Hi, > >> >> > >> >> Did anyone used USB keyboard in ddb? It looks like that once I entered > >> >> ddb, the keyboard would stop responding :( > >> > > >> > It also seems that you can't use ddb or get dumps if you boot from usb > >> > disk. > >> > >> Last time I checked it I could use ddb(4) from usb disk. > > > > hrm, ok... I'll panic again soon I'm sure, but I was getting something > > about can't do usb_polling. > > usb keyboard? No, that was on the laptop... so only usb disk. The panic was in the interrupt thread though, which is shared with usb, so that could be the issue. robert. > -- Robert Noland FreeBSD -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 196 bytes Desc: This is a digitally signed message part Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20090406/9a77b496/attachment.pgp From thierry.herbelot at free.fr Mon Apr 6 14:22:07 2009 From: thierry.herbelot at free.fr (Thierry Herbelot) Date: Mon Apr 6 14:22:15 2009 Subject: AMD 780G chipset major issues 3/3 (btx) In-Reply-To: <83e5fb980904061402q73940f8at4ec4b8f821354320@mail.gmail.com> References: <83e5fb980904061402q73940f8at4ec4b8f821354320@mail.gmail.com> Message-ID: <200904062321.47691.thierry.herbelot@free.fr> Le Monday 06 April 2009, Diego Depaoli a ?crit : > And finally... > if I enable ahci in bios the system won't boot with btx halted. > Ctrl+alt+del is the only allowed action. > > Yes... it's a low cost motherboard, but I'm a bit confused. > > Regards Hello, My latest computer is also a 780G machine (running Stable, instead of current). I initially had issues with the embedded graphics board, when the text consoles were black as soon as Xorg was started. This issue is corrected by the latest drm import (this import also gave a fully working Xvideo output : thanks) I also lost access to the DVD as long as AHCI mode was disabled ; enabling AHCI corrects this issue (and I do keep access to the three SATA disks in the machine) As with you, I am loading snd_hda via /etc/rc.local, instead of by the loader, if I want some sound output (but then, the "hda" part of the name of the driver is fully justified) there is still one last issue : I cannot use the integrated PCI slots : I have added an external board and I can't seem to see it via pciconf -lv (I did not check recently, but neither could Ubuntu see the board) After a bad start (and a certain disappointment) I'm quite happy with this little board (as I said, running -Stable) Cheers TfH PS : I still see something strange : "sometimes" (TM)(R), I must re-plug the USB mouse for it to be correctly detected From kientzle at freebsd.org Mon Apr 6 14:33:34 2009 From: kientzle at freebsd.org (Tim Kientzle) Date: Mon Apr 6 14:33:41 2009 Subject: KDE4 and input events stalled Message-ID: <49DA752B.5030805@freebsd.org> Running -CURRENT r190666 and finally got KDE4 to run (by running dbus and hald), but the mouse and keyboard input are very wonky. USB mouse and keyboard, of course. For example, if I click on a button almost anywhere in the KDE interface (including Seamonkey): - Button down - See button depress - Button up - ?? nothing happens ?? - Move mouse - Button up, event occurs I occasionally see this with keyboard input as well; keys don't appear until I move or click the mouse. This is less consistent, though. I haven't seen any evidence that events are actually getting lost; they're just getting held up somewhere. The net effect is very interesting; the whole interface felt incredibly sluggish until I learned to keep moving the mouse. Then it wasn't so bad. Tim P.S. KDE4 is very pretty; I could get used to this. From pieter at degoeje.nl Mon Apr 6 14:59:44 2009 From: pieter at degoeje.nl (Pieter de Goeje) Date: Mon Apr 6 14:59:51 2009 Subject: AMD 780G chipset major issues 2/3 (snd_hda) In-Reply-To: <83e5fb980904061402t7e07e9e7v795a27cb588ac518@mail.gmail.com> References: <83e5fb980904061402t7e07e9e7v795a27cb588ac518@mail.gmail.com> Message-ID: <200904062358.43622.pieter@degoeje.nl> On Monday 06 April 2009, Diego Depaoli wrote: > After boot > #dmesg | grep hda > hdac0: mem > 0xfeae8000-0xfeaebfff irq 19 at device 5.1 on pci1 > hdac0: HDA Driver Revision: 20090401_0132 > hdac0: [ITHREAD] > hdac1: mem > 0xfe8f4000-0xfe8f7fff irq 16 at device 20.2 on pci0 > hdac1: HDA Driver Revision: 20090401_0132 > hdac1: [ITHREAD] > hdac0: HDA Codec #0: ATI RS690/780 HDMI > pcm0: at cad 0 nid 1 on hdac0 > hdac1: HDA Codec #0: Realtek ALC662 > pcm1: at cad 0 nid 1 on hdac1 > > sound doesn't work It does (should) work, it simply plays on the HDMI port. Add hw.snd.default_unit=1 to sysctl.conf to "fix". > > #kldunload snd_hda > #kldload snd_hda > > #dmesg | grep hda > hdac0: detached > hdac1: detached > hdac0: mem > 0xfe8f4000-0xfe8f7fff irq 16 at device 20.2 on pci0 > hdac0: HDA Driver Revision: 20090401_0132 > hdac0: [ITHREAD] > hdac0: HDA Codec #0: Realtek ALC662 > hdac1: mem > 0xfeae8000-0xfeaebfff irq 19 at device 5.1 on pci1 > hdac1: HDA Driver Revision: 20090401_0132 > hdac1: [ITHREAD] > hdac1: HDA Codec #0: ATI RS690/780 HDMI > pcm0: at cad 0 nid 1 on hdac0 > pcm1: at cad 0 nid 1 on hdac1 > > Now sound works Cheers, Pieter de Goeje From gelraen.ua at gmail.com Mon Apr 6 15:00:33 2009 From: gelraen.ua at gmail.com (Maxim Ignatenko) Date: Mon Apr 6 15:00:41 2009 Subject: [patch] matching IPv4 broadcast packets in ipfw In-Reply-To: References: Message-ID: Sorry, I'm feeling really stupid... I've used | instead of & when verifying IFF_BROADCAST bit... Here is corrected patch: --- sys/netinet/ip_fw2.c.orig 2009-04-05 20:43:08.000000000 +0300 +++ sys/netinet/ip_fw2.c 2009-04-06 09:55:04.000000000 +0300 @@ -3131,6 +3131,27 @@ mtag->m_tag_id <= p[1]; } break; + case O_BROADCAST: + if (is_ipv4) + { + struct ifnet *ifp; + ifp=(oif ? oif : m->m_pkthdr.rcvif); + if (ifp == NULL || + (ifp->if_flags & IFF_BROADCAST) == 0) + break; + struct ifaddr *ia; + TAILQ_FOREACH(ia, &ifp->if_addrhead, ifa_link) { + if (ia->ifa_broadaddr == NULL || + ia->ifa_broadaddr->sa_family != AF_INET) + continue; + if (((struct sockaddr_in *)(ia->ifa_broadaddr))-> + sin_addr.s_addr == dst_ip.s_addr) { + match=1; + break; + } + } + } + break; } /* @@ -3897,6 +3918,7 @@ case O_IN: case O_FRAG: case O_DIVERTED: + case O_BROADCAST: case O_IPOPT: case O_IPTOS: case O_IPPRECEDENCE: --- sys/netinet/ip_fw.h.orig 2009-04-05 21:41:08.000000000 +0300 +++ sys/netinet/ip_fw.h 2009-04-05 21:46:23.000000000 +0300 @@ -179,6 +179,8 @@ O_SETFIB, /* arg1=FIB number */ O_FIB, /* arg1=FIB desired fib number */ + O_BROADCAST, /* matches IP packets sent on broadcast address */ + O_LAST_OPCODE /* not an opcode! */ }; --- sbin/ipfw/ipfw2.c.orig 2009-04-05 21:23:38.000000000 +0300 +++ sbin/ipfw/ipfw2.c 2009-04-06 09:25:39.000000000 +0300 @@ -291,6 +291,7 @@ { "src-ipv6", TOK_SRCIP6}, { "src-ip6", TOK_SRCIP6}, { "//", TOK_COMMENT }, + { "broadcast", TOK_BROADCAST}, { "not", TOK_NOT }, /* pseudo option */ { "!", /* escape ? */ TOK_NOT }, /* pseudo option */ @@ -1506,6 +1507,10 @@ print_newports((ipfw_insn_u16 *)cmd, 0, O_TAGGED); break; + + case O_BROADCAST: + printf(" broadcast"); + break; default: printf(" [opcode %d len %d]", @@ -3455,6 +3460,10 @@ ac = 0; break; + case TOK_BROADCAST: + fill_cmd(cmd, O_BROADCAST, 0, 0); + break; + case TOK_TAGGED: if (ac > 0 && strpbrk(*av, "-,")) { if (!add_ports(cmd, *av, 0, O_TAGGED)) --- sbin/ipfw/ipfw2.h.orig 2009-04-05 21:23:47.000000000 +0300 +++ sbin/ipfw/ipfw2.h 2009-04-05 21:27:22.000000000 +0300 @@ -141,6 +141,7 @@ TOK_ANTISPOOF, TOK_IPSEC, TOK_COMMENT, + TOK_BROADCAST, TOK_PLR, TOK_NOERROR, --- sbin/ipfw/ipfw.8.orig 2009-04-06 02:10:47.000000000 +0300 +++ sbin/ipfw/ipfw.8 2009-04-06 02:13:54.000000000 +0300 @@ -1135,6 +1135,8 @@ .It Cm bridged Alias for .Cm layer2 . +.It Cm broadcast +Matches broadcast packets on non-point-to-point interfaces. .It Cm diverted Matches only packets generated by a divert socket. .It Cm diverted-loopback From lxwaycell at gmail.com Mon Apr 6 15:24:16 2009 From: lxwaycell at gmail.com (Xu Lian) Date: Mon Apr 6 15:24:23 2009 Subject: KDE4 and input events stalled In-Reply-To: <934e1d760904061438k7d70d683re5c9d9a29e311942@mail.gmail.com> References: <49DA752B.5030805@freebsd.org> <934e1d760904061438k7d70d683re5c9d9a29e311942@mail.gmail.com> Message-ID: <934e1d760904061455o4736d643o1d07e3292192d94c@mail.gmail.com> On Tue, Apr 7, 2009 at 5:38 AM, Xu Lian wrote: > > > On Tue, Apr 7, 2009 at 5:33 AM, Tim Kientzle wrote: > >> Running -CURRENT r190666 and finally got KDE4 >> to run (by running dbus and hald), but the mouse >> and keyboard input are very wonky. USB mouse >> and keyboard, of course. >> >> For example, if I click on a button almost >> anywhere in the KDE interface (including >> Seamonkey): >> - Button down >> - See button depress >> - Button up >> - ?? nothing happens ?? >> - Move mouse >> - Button up, event occurs >> >> I occasionally see this with keyboard input >> as well; keys don't appear until I move or >> click the mouse. This is less consistent, >> though. >> >> I haven't seen any evidence that events >> are actually getting lost; they're just >> getting held up somewhere. >> >> The net effect is very interesting; the >> whole interface felt incredibly sluggish until >> I learned to keep moving the mouse. Then >> it wasn't so bad. >> >> Tim >> >> P.S. KDE4 is very pretty; I could get used to this. >> >> _______________________________________________ >> freebsd-current@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-current >> To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org >> " >> > I also run kde4.2.2 on current,not this error(i use wacom drive with some > little hack =P),check your xorg.conf and KDE System Settings > From Thomas.Sparrevohn at btinternet.com Mon Apr 6 15:27:01 2009 From: Thomas.Sparrevohn at btinternet.com (Thomas Sparrevohn) Date: Mon Apr 6 15:27:08 2009 Subject: ZFS checksum errors on USB attach (Was: ZFS data error without reasons) In-Reply-To: <20090405015627.GB47968@plebeian.afflictions.org> References: <49BD117B.2080706@163.com> <20090331100328.H46640@rust.salford.ac.uk> <20090401044011.GA51164@plebeian.afflictions.org> <200904010846.55770.hselasky@c2i.net> <20090401121704.GA92522@plebeian.afflictions.org> <20090401234315.GA11125@plebeian.afflictions.org> <20090405015627.GB47968@plebeian.afflictions.org> Message-ID: <012d01c9b706$ccace720$6606b560$@Sparrevohn@btinternet.com> Just a me too - Here - I just seen significant corruption of a newly restored pool - the system had been running a portupgrade - I am getting worried - but the disks shows no errors - neither from the ATA subsystem nor from smartctl or some vendor testing tools I have -----Original Message----- From: owner-freebsd-current@freebsd.org [mailto:owner-freebsd-current@freebsd.org] On Behalf Of Damian Gerow Sent: 05 April 2009 02:56 To: freebsd-current@freebsd.org Subject: Re: ZFS checksum errors on USB attach (Was: ZFS data error without reasons) I've filed kern/133373 to track this. _______________________________________________ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" From Thomas.Sparrevohn at btinternet.com Mon Apr 6 15:27:56 2009 From: Thomas.Sparrevohn at btinternet.com (Thomas Sparrevohn) Date: Mon Apr 6 15:28:03 2009 Subject: ZFS checksum errors on USB attach (Was: ZFS data error without reasons) In-Reply-To: <20090405015627.GB47968@plebeian.afflictions.org> References: <49BD117B.2080706@163.com> <20090331100328.H46640@rust.salford.ac.uk> <20090401044011.GA51164@plebeian.afflictions.org> <200904010846.55770.hselasky@c2i.net> <20090401121704.GA92522@plebeian.afflictions.org> <20090401234315.GA11125@plebeian.afflictions.org> <20090405015627.GB47968@plebeian.afflictions.org> Message-ID: <012e01c9b706$edefeae0$c9cfc0a0$@Sparrevohn@btinternet.com> PS - The kernel paniced in ZFS when I tried to scrub the pool - I send a crash dump -----Original Message----- From: owner-freebsd-current@freebsd.org [mailto:owner-freebsd-current@freebsd.org] On Behalf Of Damian Gerow Sent: 05 April 2009 02:56 To: freebsd-current@freebsd.org Subject: Re: ZFS checksum errors on USB attach (Was: ZFS data error without reasons) I've filed kern/133373 to track this. _______________________________________________ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" From sam at freebsd.org Mon Apr 6 15:36:30 2009 From: sam at freebsd.org (Sam Leffler) Date: Mon Apr 6 15:36:37 2009 Subject: KDE4 and input events stalled In-Reply-To: <49DA752B.5030805@freebsd.org> References: <49DA752B.5030805@freebsd.org> Message-ID: <49DA83ED.3070905@freebsd.org> Tim Kientzle wrote: > Running -CURRENT r190666 and finally got KDE4 > to run (by running dbus and hald), but the mouse > and keyboard input are very wonky. USB mouse > and keyboard, of course. > > For example, if I click on a button almost > anywhere in the KDE interface (including > Seamonkey): > - Button down > - See button depress > - Button up > - ?? nothing happens ?? > - Move mouse > - Button up, event occurs > > I occasionally see this with keyboard input > as well; keys don't appear until I move or > click the mouse. This is less consistent, > though. > > I haven't seen any evidence that events > are actually getting lost; they're just > getting held up somewhere. > > The net effect is very interesting; the > whole interface felt incredibly sluggish until > I learned to keep moving the mouse. Then > it wasn't so bad. > > Tim > > P.S. KDE4 is very pretty; I could get used to this. I installed KDE4 on one laptop and it seemed to work ok w/ both the touchpad and a usb mouse. This is using hald+dbus. Note I run the laptop very infrequently and it's not been updated for a few weeks. Sam From rnoland at FreeBSD.org Mon Apr 6 15:44:24 2009 From: rnoland at FreeBSD.org (Robert Noland) Date: Mon Apr 6 15:44:31 2009 Subject: KDE4 and input events stalled In-Reply-To: <934e1d760904061455o4736d643o1d07e3292192d94c@mail.gmail.com> References: <49DA752B.5030805@freebsd.org> <934e1d760904061438k7d70d683re5c9d9a29e311942@mail.gmail.com> <934e1d760904061455o4736d643o1d07e3292192d94c@mail.gmail.com> Message-ID: <1239057809.1908.2.camel@balrog.2hip.net> On Tue, 2009-04-07 at 05:55 +0800, Xu Lian wrote: > On Tue, Apr 7, 2009 at 5:38 AM, Xu Lian wrote: > > > > > > > On Tue, Apr 7, 2009 at 5:33 AM, Tim Kientzle wrote: > > > >> Running -CURRENT r190666 and finally got KDE4 > >> to run (by running dbus and hald), but the mouse > >> and keyboard input are very wonky. USB mouse > >> and keyboard, of course. > >> > >> For example, if I click on a button almost > >> anywhere in the KDE interface (including > >> Seamonkey): > >> - Button down > >> - See button depress > >> - Button up > >> - ?? nothing happens ?? > >> - Move mouse > >> - Button up, event occurs > >> > >> I occasionally see this with keyboard input > >> as well; keys don't appear until I move or > >> click the mouse. This is less consistent, > >> though. Let me guess, you are using Intel graphics? robert. > >> I haven't seen any evidence that events > >> are actually getting lost; they're just > >> getting held up somewhere. > >> > >> The net effect is very interesting; the > >> whole interface felt incredibly sluggish until > >> I learned to keep moving the mouse. Then > >> it wasn't so bad. > >> > >> Tim > >> > >> P.S. KDE4 is very pretty; I could get used to this. > >> > >> _______________________________________________ > >> freebsd-current@freebsd.org mailing list > >> http://lists.freebsd.org/mailman/listinfo/freebsd-current > >> To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org > >> " > >> > > I also run kde4.2.2 on current,not this error(i use wacom drive with some > > little hack =P),check your xorg.conf and KDE System Settings > > > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" -- Robert Noland FreeBSD -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 196 bytes Desc: This is a digitally signed message part Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20090406/22e6c579/attachment.pgp From debardeleben at aol.com Mon Apr 6 17:41:37 2009 From: debardeleben at aol.com (debardeleben@aol.com) Date: Mon Apr 6 17:41:44 2009 Subject: KDE and input events. Message-ID: <8CB8530B963508E-D10-12E5@WEBMAIL-MA11.sysops.aol.com> Are you running -CURRENT? I have found that my bluetooth logitech mx-revolution mouse is broken yet again. I am seeing stuff like you are seeing, where the buttons are just whacky. usually the left button is permanently pushed, but at the moment I am getting no motion events out of it. All of my recent issues started when I updated to a version that included r190741 but I have not yet proven this to be the source. For now I am using the mouse pad on my dinovo keyboard, which seams to work. Anyone know what the change to hid processing is for? so far every time it is changed, my mouse stops working? until someone restores some old code that is usually described as unneeded or a work around for some other bug. Is there maybe a bug in the Logitech HID implementation? -Charles From debardeleben at aol.com Mon Apr 6 18:39:05 2009 From: debardeleben at aol.com (debardeleben@aol.com) Date: Mon Apr 6 18:39:13 2009 Subject: KDE and input events. In-Reply-To: <8CB8530B963508E-D10-12E5@WEBMAIL-MA11.sysops.aol.com> References: <8CB8530B963508E-D10-12E5@WEBMAIL-MA11.sysops.aol.com> Message-ID: <8CB8538B792B51B-388-26F6@webmail-dd11.sysops.aol.com> I updated to r190788, and reset the internal state of my mouse using windows and it works now. I do not know if recent changes fixed it or if the mouse just needed a reset. In any case it looks as though current -CURRENT works with my mouse. -Charles -----Original Message----- From: debardeleben@aol.com To: freebsd-current@freebsd.org Sent: Mon, 6 Apr 2009 5:41 pm Subject: Re: KDE and input events. Are you running -CURRENT? I have found that my bluetooth logitech mx-revolution mouse is broken yet again. I am seeing stuff like you are seeing, where the buttons are just whacky. usually the left button is permanently pushed, but at the moment I am getting no motion events out of it. All of my recent issues started when I updated to a version that included r190741 but I have not yet proven this to be the source. For now I am using the mouse pad on my dinovo keyboard, which seams to work. Anyone know what the change to hid processing is for? so far every time it is changed, my mouse stops working? until someone restores some old code that is usually described as unneeded or a work around for some other bug. Is there maybe a bug in the Logitech HID implementation? -Charles _______________________________________________ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" From kientzle at freebsd.org Mon Apr 6 18:45:31 2009 From: kientzle at freebsd.org (Tim Kientzle) Date: Mon Apr 6 18:45:39 2009 Subject: KDE4 and input events stalled In-Reply-To: <49DA752B.5030805@freebsd.org> References: <49DA752B.5030805@freebsd.org> Message-ID: <49DAB039.1000309@freebsd.org> Tim Kientzle wrote: > Running -CURRENT r190666 and finally got KDE4 > to run (by running dbus and hald), but the mouse > and keyboard input are very wonky. USB mouse > and keyboard, of course. > > For example, if I click on a button almost > anywhere in the KDE interface (including > Seamonkey): > - Button down > - See button depress > - Button up > - ?? nothing happens ?? > - Move mouse > - Button up, event occurs > > I occasionally see this with keyboard input > as well; keys don't appear until I move or > click the mouse. This is less consistent, > though. Solved that problem: I had gotten x.org working without hald, which required adding this to /etc/X11/xorg.conf: Section "ServerFlags" Option "AllowEmptyInput" "off" EndSection Of course, KDE4 required me to enable hald, which requires removing that option . Removing it fixed my input wonkiness. Now to dig out the instructions for getting my Ctrl key back when using hald. Then, I'll try to figure out why kdm works if I start it manually after the system is running but kills the screen if I try starting it from /etc/ttys. Tim From weongyo.jeong at gmail.com Mon Apr 6 19:57:57 2009 From: weongyo.jeong at gmail.com (Weongyo Jeong) Date: Mon Apr 6 19:58:03 2009 Subject: HEADSUP: uath(4) has been committed. Message-ID: <20090407022956.GA71377@weongyo.cdnetworks.kr> Hello, FYI uath(4) driver has been committed into HEAD. To work with uath(4) it needs to load the firmware using uathload. The example would be as follows: # kldload if_uath [plugin Atheros USB stick] ugen0.2: at usbus0 # uathload -d /dev/ugen0.2 [after downloading the firmware it'll retry to attach] # ifconfig uath0 Normally uathload could be found at /usr/sbin or /usr/src/usr.sbin/uathload for sources and if you don't want to execute uathload by hand it'd be better to add a entry into devd.conf(5). regards, Weongyo Jeong From kientzle at freebsd.org Mon Apr 6 20:23:48 2009 From: kientzle at freebsd.org (Tim Kientzle) Date: Mon Apr 6 20:23:54 2009 Subject: KDE4 and input events stalled In-Reply-To: <1239057809.1908.2.camel@balrog.2hip.net> References: <49DA752B.5030805@freebsd.org> <934e1d760904061438k7d70d683re5c9d9a29e311942@mail.gmail.com> <934e1d760904061455o4736d643o1d07e3292192d94c@mail.gmail.com> <1239057809.1908.2.camel@balrog.2hip.net> Message-ID: <49DAC742.8090507@freebsd.org> Robert Noland wrote: > >>> On Tue, Apr 7, 2009 at 5:33 AM, Tim Kientzle wrote: >>> >>>> For example, if I click on a button almost >>>> anywhere in the KDE interface (including >>>> Seamonkey): >>>> - Button down >>>> - See button depress >>>> - Button up >>>> - ?? nothing happens ?? >>>> - Move mouse >>>> - Button up, event occurs > > Let me guess, you are using Intel graphics? Ummm... Okay, what do you know that I don't? I fixed the input problem by setting "AcceptEmptyInput" appropriately[1]. Now, I have two other problems I'm trying to track down, either of which could be related to using Intel graphics: * On logout, screen dies (garbage all over). /var/log/messages reports that the Xorg server died with a segfault; I presume this left the graphics card in a bad state. Alt-Ctrl-F1 changes the garbage on the screen but doesn't recover the screen. * If I start kdm from /etc/ttys, I get a blank screen on startup. If I start it from a root login, it works okay for the first login. Still digging... Tim [1] If I understand correctly, "AcceptEmptyInput" is now mandatory if you are not using hald and forbidden if you are. Is there a reason for the Xorg server not to set it automatically? From rnoland at FreeBSD.org Mon Apr 6 20:40:17 2009 From: rnoland at FreeBSD.org (Robert Noland) Date: Mon Apr 6 20:40:23 2009 Subject: KDE4 and input events stalled In-Reply-To: <49DAC742.8090507@freebsd.org> References: <49DA752B.5030805@freebsd.org> <934e1d760904061438k7d70d683re5c9d9a29e311942@mail.gmail.com> <934e1d760904061455o4736d643o1d07e3292192d94c@mail.gmail.com> <1239057809.1908.2.camel@balrog.2hip.net> <49DAC742.8090507@freebsd.org> Message-ID: <1239075455.1908.36.camel@balrog.2hip.net> On Mon, 2009-04-06 at 20:23 -0700, Tim Kientzle wrote: > Robert Noland wrote: > > > >>> On Tue, Apr 7, 2009 at 5:33 AM, Tim Kientzle wrote: > >>> > >>>> For example, if I click on a button almost > >>>> anywhere in the KDE interface (including > >>>> Seamonkey): > >>>> - Button down > >>>> - See button depress > >>>> - Button up > >>>> - ?? nothing happens ?? > >>>> - Move mouse > >>>> - Button up, event occurs > > > > Let me guess, you are using Intel graphics? > > Ummm... Okay, what do you know that I don't? > > I fixed the input problem by setting "AcceptEmptyInput" > appropriately[1]. > > Now, I have two other problems I'm trying to > track down, either of which could be related to > using Intel graphics: > * On logout, screen dies (garbage all over). > /var/log/messages reports that the Xorg server > died with a segfault; I presume this left the > graphics card in a bad state. Alt-Ctrl-F1 changes > the garbage on the screen but doesn't recover the > screen. This is definately broken on at least some Intel chips at the moment... I'm working on it... I find that if I kill X by stopping gdm, things seem to be ok... Using the logout or reset options in the gnome menus does bad things... > * If I start kdm from /etc/ttys, I get a blank > screen on startup. If I start it from a root > login, it works okay for the first login. This sounds more like it is waiting on hal/dbus to start up than anything. You might try using Option "AutoAddDevices" "off" in place of or in addition to AllowEmptyInput. robert. > Still digging... > > Tim > > [1] If I understand correctly, "AcceptEmptyInput" > is now mandatory if you are not using hald and > forbidden if you are. Is there a reason for > the Xorg server not to set it automatically? > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" -- Robert Noland FreeBSD -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 196 bytes Desc: This is a digitally signed message part Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20090407/c74ad3cd/attachment.pgp From pyunyh at gmail.com Mon Apr 6 20:45:20 2009 From: pyunyh at gmail.com (Pyun YongHyeon) Date: Mon Apr 6 20:45:26 2009 Subject: HEADSUP: uath(4) has been committed. In-Reply-To: <20090407022956.GA71377@weongyo.cdnetworks.kr> References: <20090407022956.GA71377@weongyo.cdnetworks.kr> Message-ID: <20090407034458.GA37714@michelle.cdnetworks.co.kr> On Tue, Apr 07, 2009 at 11:29:56AM +0900, Weongyo Jeong wrote: > Hello, > > FYI uath(4) driver has been committed into HEAD. To work with uath(4) Thanks for your hard work! > it needs to load the firmware using uathload. The example would be as > follows: > > # kldload if_uath > [plugin Atheros USB stick] > ugen0.2: at usbus0 > # uathload -d /dev/ugen0.2 > [after downloading the firmware it'll retry to attach] > # ifconfig uath0 > > Normally uathload could be found at /usr/sbin or > /usr/src/usr.sbin/uathload for sources and if you don't want to execute > uathload by hand it'd be better to add a entry into devd.conf(5). > It would be even better if the above instructions could be get into uath(4) or uathload(1) man pages. From kientzle at freebsd.org Mon Apr 6 20:51:27 2009 From: kientzle at freebsd.org (Tim Kientzle) Date: Mon Apr 6 20:51:34 2009 Subject: KDE4 and input events stalled In-Reply-To: <1239075455.1908.36.camel@balrog.2hip.net> References: <49DA752B.5030805@freebsd.org> <934e1d760904061438k7d70d683re5c9d9a29e311942@mail.gmail.com> <934e1d760904061455o4736d643o1d07e3292192d94c@mail.gmail.com> <1239057809.1908.2.camel@balrog.2hip.net> <49DAC742.8090507@freebsd.org> <1239075455.1908.36.camel@balrog.2hip.net> Message-ID: <49DACDBD.3030809@freebsd.org> >> Now, I have two other problems I'm trying to >> track down, either of which could be related to >> using Intel graphics: >> * On logout, screen dies (garbage all over). >> /var/log/messages reports that the Xorg server >> died with a segfault... > > This is definately broken on at least some Intel chips at the moment... > I'm working on it... I find that if I kill X by stopping gdm, things > seem to be ok... Using the logout or reset options in the gnome menus > does bad things... I'll play with a few things. For the record: agp0: on vgapci0 I do have an Xorg.core here if a backtrace would help at all. >> * If I start kdm from /etc/ttys, I get a blank >> screen on startup. If I start it from a root >> login, it works okay for the first login. > > This sounds more like it is waiting on hal/dbus to start up than > anything. You might try using Option "AutoAddDevices" "off" in place of > or in addition to AllowEmptyInput. Startup messages claim that dbus and hal are both running at that point. Maybe I should try adding a sleep to the hal/dbus startups and see if that changes anything? Cheers, Tim From kientzle at freebsd.org Mon Apr 6 21:05:24 2009 From: kientzle at freebsd.org (Tim Kientzle) Date: Mon Apr 6 21:05:34 2009 Subject: KDE4 problems (was Re: KDE4 and input events stalled) In-Reply-To: <49DACDBD.3030809@freebsd.org> References: <49DA752B.5030805@freebsd.org> <934e1d760904061438k7d70d683re5c9d9a29e311942@mail.gmail.com> <934e1d760904061455o4736d643o1d07e3292192d94c@mail.gmail.com> <1239057809.1908.2.camel@balrog.2hip.net> <49DAC742.8090507@freebsd.org> <1239075455.1908.36.camel@balrog.2hip.net> <49DACDBD.3030809@freebsd.org> Message-ID: <49DAD102.4070700@freebsd.org> Tim Kientzle wrote: >>> * On logout, screen dies (garbage all over). >>> /var/log/messages reports that the Xorg server >>> died with a segfault... >> >> This is definately broken on at least some Intel chips at the moment... >> I'm working on it... I find that if I kill X by stopping gdm, things >> seem to be ok... Enabling "TerminateServer" in the kdmrc file seems to work around this. I still get a /Xorg.core file but kdm seems to recover and allow me to login again. BUT, now Ctrl-Alt-F# shows a messed-up console (Ctrl-Alt-F9 gets back into KDE just fine). Clearly, the video card is still getting wonked. I'll see if I can build an Xorg server with debug symbols and get a backtrace. > I'll play with a few things. For the record: > agp0: on vgapci0 From rnoland at FreeBSD.org Mon Apr 6 21:07:42 2009 From: rnoland at FreeBSD.org (Robert Noland) Date: Mon Apr 6 21:07:49 2009 Subject: KDE4 and input events stalled In-Reply-To: <49DACDBD.3030809@freebsd.org> References: <49DA752B.5030805@freebsd.org> <934e1d760904061438k7d70d683re5c9d9a29e311942@mail.gmail.com> <934e1d760904061455o4736d643o1d07e3292192d94c@mail.gmail.com> <1239057809.1908.2.camel@balrog.2hip.net> <49DAC742.8090507@freebsd.org> <1239075455.1908.36.camel@balrog.2hip.net> <49DACDBD.3030809@freebsd.org> Message-ID: <1239077210.1908.39.camel@balrog.2hip.net> On Mon, 2009-04-06 at 20:51 -0700, Tim Kientzle wrote: > >> Now, I have two other problems I'm trying to > >> track down, either of which could be related to > >> using Intel graphics: > >> * On logout, screen dies (garbage all over). > >> /var/log/messages reports that the Xorg server > >> died with a segfault... > > > > This is definately broken on at least some Intel chips at the moment... > > I'm working on it... I find that if I kill X by stopping gdm, things > > seem to be ok... Using the logout or reset options in the gnome menus > > does bad things... > > I'll play with a few things. For the record: > agp0: on vgapci0 > > I do have an Xorg.core here if a backtrace would > help at all. > > >> * If I start kdm from /etc/ttys, I get a blank > >> screen on startup. If I start it from a root > >> login, it works okay for the first login. > > > > This sounds more like it is waiting on hal/dbus to start up than > > anything. You might try using Option "AutoAddDevices" "off" in place of > > or in addition to AllowEmptyInput. > > Startup messages claim that dbus and hal are both running at > that point. Maybe I should try adding a sleep to the hal/dbus > startups and see if that changes anything? So, basically X should wait on hal/dbus t become ready. dbus has to come up first, then hald registers with dbus. What happens if you just leave it for a minute? Does it ever come up? robert. > Cheers, > > Tim > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" -- Robert Noland FreeBSD -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 196 bytes Desc: This is a digitally signed message part Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20090407/c3ab0527/attachment.pgp From mdc at prgmr.com Mon Apr 6 21:17:49 2009 From: mdc at prgmr.com (Michael David Crawford) Date: Mon Apr 6 21:17:56 2009 Subject: ddb can't use USB keyboard? In-Reply-To: <1239052841.1868.3.camel@balrog.2hip.net> References: <49D99F42.5040104@delphij.net> <1239039350.1852.1.camel@balrog.2hip.net> <3a142e750904061359iea7fe97mc69825ddba10bf85@mail.gmail.com> <1239051941.1868.1.camel@balrog.2hip.net> <3a142e750904061407nc0d24ceme07edfaf4fb3c7a5@mail.gmail.com> <1239052841.1868.3.camel@balrog.2hip.net> Message-ID: <49DAD3CF.3010503@prgmr.com> Robert Noland wrote: > No, that was on the laptop... so only usb disk. The keyboards on many laptops are actually USB, just internally connected. Does your laptop also have an external PS/2 port? If so, you could debug with that. Mike -- Michael David Crawford mdc@prgmr.com prgmr.com - We Don't Assume You Are Stupid. Xen-Powered Virtual Private Servers: http://prgmr.com/xen From kientzle at freebsd.org Mon Apr 6 21:18:51 2009 From: kientzle at freebsd.org (Tim Kientzle) Date: Mon Apr 6 21:18:58 2009 Subject: KDE4 and input events stalled In-Reply-To: <1239077210.1908.39.camel@balrog.2hip.net> References: <49DA752B.5030805@freebsd.org> <934e1d760904061438k7d70d683re5c9d9a29e311942@mail.gmail.com> <934e1d760904061455o4736d643o1d07e3292192d94c@mail.gmail.com> <1239057809.1908.2.camel@balrog.2hip.net> <49DAC742.8090507@freebsd.org> <1239075455.1908.36.camel@balrog.2hip.net> <49DACDBD.3030809@freebsd.org> <1239077210.1908.39.camel@balrog.2hip.net> Message-ID: <49DAD429.6090309@freebsd.org> >>>> * If I start kdm from /etc/ttys, I get a blank >>>> screen on startup. If I start it from a root >>>> login, it works okay for the first login. >>> This sounds more like it is waiting on hal/dbus to start up than >>> anything. > > So, basically X should wait on hal/dbus t become ready. Looking at the code, this might be impossible. /usr/local/etc/rc.d/hal does some very strange gyrations to delay its own start until after at least one getty process has started. That would make it highly improbable that hal can start before X if X is being started from /etc/ttys. I'm not familiar enough with hal to know why it might want to do this. Any ideas? Tim From rnoland at FreeBSD.org Mon Apr 6 21:22:11 2009 From: rnoland at FreeBSD.org (Robert Noland) Date: Mon Apr 6 21:22:17 2009 Subject: KDE4 and input events stalled In-Reply-To: <49DAD429.6090309@freebsd.org> References: <49DA752B.5030805@freebsd.org> <934e1d760904061438k7d70d683re5c9d9a29e311942@mail.gmail.com> <934e1d760904061455o4736d643o1d07e3292192d94c@mail.gmail.com> <1239057809.1908.2.camel@balrog.2hip.net> <49DAC742.8090507@freebsd.org> <1239075455.1908.36.camel@balrog.2hip.net> <49DACDBD.3030809@freebsd.org> <1239077210.1908.39.camel@balrog.2hip.net> <49DAD429.6090309@freebsd.org> Message-ID: <1239078081.1908.41.camel@balrog.2hip.net> On Mon, 2009-04-06 at 21:18 -0700, Tim Kientzle wrote: > >>>> * If I start kdm from /etc/ttys, I get a blank > >>>> screen on startup. If I start it from a root > >>>> login, it works okay for the first login. > >>> This sounds more like it is waiting on hal/dbus to start up than > >>> anything. > > > > So, basically X should wait on hal/dbus t become ready. > > Looking at the code, this might be impossible. > > /usr/local/etc/rc.d/hal does some very strange > gyrations to delay its own start until after > at least one getty process has started. That would > make it highly improbable that hal can start before X > if X is being started from /etc/ttys. > > I'm not familiar enough with hal to know why it might > want to do this. Any ideas? It's ok for hal to start later... It's dbus that has to be alive. As long as dbus is up, X will wait around on hal to show up for a bit. robert. > Tim -- Robert Noland FreeBSD -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 196 bytes Desc: This is a digitally signed message part Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20090407/aae774f5/attachment.pgp From rnoland at FreeBSD.org Mon Apr 6 21:25:44 2009 From: rnoland at FreeBSD.org (Robert Noland) Date: Mon Apr 6 21:25:51 2009 Subject: ddb can't use USB keyboard? In-Reply-To: <49DAD3CF.3010503@prgmr.com> References: <49D99F42.5040104@delphij.net> <1239039350.1852.1.camel@balrog.2hip.net> <3a142e750904061359iea7fe97mc69825ddba10bf85@mail.gmail.com> <1239051941.1868.1.camel@balrog.2hip.net> <3a142e750904061407nc0d24ceme07edfaf4fb3c7a5@mail.gmail.com> <1239052841.1868.3.camel@balrog.2hip.net> <49DAD3CF.3010503@prgmr.com> Message-ID: <1239078295.1908.44.camel@balrog.2hip.net> On Mon, 2009-04-06 at 21:17 -0700, Michael David Crawford wrote: > Robert Noland wrote: > > No, that was on the laptop... so only usb disk. > > The keyboards on many laptops are actually USB, just internally > connected. Does your laptop also have an external PS/2 port? If so, > you could debug with that. Now that you mention it, no... it doesn't. Basically the error I get when it panics is "usb2_do_poll: Polling not supported" I was working on some other stuff yesterday and after a long while, something timed out and it tried to dump a core, but the disk wasn't available. robert. > Mike -- Robert Noland FreeBSD -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 196 bytes Desc: This is a digitally signed message part Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20090407/aa0ea400/attachment.pgp From kientzle at freebsd.org Mon Apr 6 22:50:01 2009 From: kientzle at freebsd.org (Tim Kientzle) Date: Mon Apr 6 22:50:07 2009 Subject: Hal and KDM breakage (was Re: KDE4 and input events stalled) In-Reply-To: <1239078081.1908.41.camel@balrog.2hip.net> References: <49DA752B.5030805@freebsd.org> <934e1d760904061438k7d70d683re5c9d9a29e311942@mail.gmail.com> <934e1d760904061455o4736d643o1d07e3292192d94c@mail.gmail.com> <1239057809.1908.2.camel@balrog.2hip.net> <49DAC742.8090507@freebsd.org> <1239075455.1908.36.camel@balrog.2hip.net> <49DACDBD.3030809@freebsd.org> <1239077210.1908.39.camel@balrog.2hip.net> <49DAD429.6090309@freebsd.org> <1239078081.1908.41.camel@balrog.2hip.net> Message-ID: <49DAE987.7090802@freebsd.org> Robert Noland wrote: > On Mon, 2009-04-06 at 21:18 -0700, Tim Kientzle wrote: >>>>>> * If I start kdm from /etc/ttys, I get a blank >>>>>> screen on startup. If I start it from a root >>>>>> login, it works okay for the first login. >>>>> This sounds more like it is waiting on hal/dbus to start up than >>>>> anything. Yep, that seems to be the issue. I got it to work finally by commenting out this one line from /usr/local/etc/rc.d/hald: #start_cmd="hald_start" In particular, this allows hald to startup in the regular sequence without that odd delay. Tim CCing marcus@; maybe he can explain why that delay was put in and whether ripping it back out makes sense. From marcus at FreeBSD.org Mon Apr 6 23:40:09 2009 From: marcus at FreeBSD.org (Joe Marcus Clarke) Date: Mon Apr 6 23:40:16 2009 Subject: Hal and KDM breakage (was Re: KDE4 and input events stalled) In-Reply-To: <49DAE987.7090802@freebsd.org> References: <49DA752B.5030805@freebsd.org> <934e1d760904061438k7d70d683re5c9d9a29e311942@mail.gmail.com> <934e1d760904061455o4736d643o1d07e3292192d94c@mail.gmail.com> <1239057809.1908.2.camel@balrog.2hip.net> <49DAC742.8090507@freebsd.org> <1239075455.1908.36.camel@balrog.2hip.net> <49DACDBD.3030809@freebsd.org> <1239077210.1908.39.camel@balrog.2hip.net> <49DAD429.6090309@freebsd.org> <1239078081.1908.41.camel@balrog.2hip.net> <49DAE987.7090802@freebsd.org> Message-ID: <1239086408.35025.59.camel@shumai.marcuscom.com> On Mon, 2009-04-06 at 22:49 -0700, Tim Kientzle wrote: > Robert Noland wrote: > > On Mon, 2009-04-06 at 21:18 -0700, Tim Kientzle wrote: > >>>>>> * If I start kdm from /etc/ttys, I get a blank > >>>>>> screen on startup. If I start it from a root > >>>>>> login, it works okay for the first login. > >>>>> This sounds more like it is waiting on hal/dbus to start up than > >>>>> anything. > > Yep, that seems to be the issue. I got > it to work finally by commenting out this > one line from /usr/local/etc/rc.d/hald: > > #start_cmd="hald_start" > > In particular, this allows hald to startup > in the regular sequence without that > odd delay. The problem is due to the fact that console-kit-daemon will not work if it starts up before init has started the ttys. Therefore, hald needs to come up after the getty processes have been spawned (i.e. after init has started the ttys). If the ttys were started as part of the rc.d process, this could be avoided. This is why GNOME makes people use the rc.d script to start gdm. It just won't work out of /etc/ttys. Joe -- Joe Marcus Clarke FreeBSD GNOME Team :: gnome@FreeBSD.org FreeNode / #freebsd-gnome http://www.FreeBSD.org/gnome -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: This is a digitally signed message part Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20090407/ecbfae42/attachment.pgp From hselasky at c2i.net Mon Apr 6 23:56:45 2009 From: hselasky at c2i.net (Hans Petter Selasky) Date: Mon Apr 6 23:56:52 2009 Subject: ddb can't use USB keyboard? In-Reply-To: <1239052841.1868.3.camel@balrog.2hip.net> References: <49D99F42.5040104@delphij.net> <3a142e750904061407nc0d24ceme07edfaf4fb3c7a5@mail.gmail.com> <1239052841.1868.3.camel@balrog.2hip.net> Message-ID: <200904070858.27259.hselasky@c2i.net> Hi, The polling error is just there to inform you that USB polling is not supported: void usb2_do_poll(struct usb2_xfer **ppxfer, uint16_t max) { static uint8_t once = 0; /* polling is currently not supported */ if (!once) { once = 1; printf("usb2_do_poll: USB polling is " "not supported!\n"); } } The biggest problem getting polling working is that USB is now multithreaded. But I don't rule out that we could have some special mechanism to get one of the system USB keyboards up in DDB. Secondly, ukbd is Giant locked, and actually DDB calls into the keyboard routines without locking Giant, and that will not work with USB. --HPS From M.S.Powell at salford.ac.uk Tue Apr 7 01:59:21 2009 From: M.S.Powell at salford.ac.uk (Mark Powell) Date: Tue Apr 7 02:00:53 2009 Subject: AMD 780G chipset major issues 3/3 (btx) In-Reply-To: <200904062321.47691.thierry.herbelot@free.fr> References: <83e5fb980904061402q73940f8at4ec4b8f821354320@mail.gmail.com> <200904062321.47691.thierry.herbelot@free.fr> Message-ID: <20090407095804.G8569@rust.salford.ac.uk> On Mon, 6 Apr 2009, Thierry Herbelot wrote: > Le Monday 06 April 2009, Diego Depaoli a ?crit : >> And finally... >> if I enable ahci in bios the system won't boot with btx halted. >> Ctrl+alt+del is the only allowed action. >> >> Yes... it's a low cost motherboard, but I'm a bit confused. > > My latest computer is also a 780G machine (running Stable, instead of > current). Could we have some make/models guys? I'm interested in a new integrated graphics MB for CURRENT and want to know what to avoid. Cheers. -- Mark Powell - UNIX System Administrator - The University of Salford Information & Learning Services, Clifford Whitworth Building, Salford University, Manchester, M5 4WT, UK. Tel: +44 161 295 6843 Fax: +44 161 295 5888 www.pgp.com for PGP key From ivoras at freebsd.org Tue Apr 7 02:04:00 2009 From: ivoras at freebsd.org (Ivan Voras) Date: Tue Apr 7 02:04:28 2009 Subject: AMD Opteron CPU PMC patch In-Reply-To: <4451ccf20904061110m91da3del8d39d81132a4dc48@mail.gmail.com> References: <4451ccf20904061110m91da3del8d39d81132a4dc48@mail.gmail.com> Message-ID: ??ccuiyyan@sina.com wrote: > Hi all : > > Are there any patches available in FreeBSD-current 8.0 for AMD Opteron > CPU to support PMC? Ok, Google loses and you win. What is PMC? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 252 bytes Desc: OpenPGP digital signature Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20090407/4296cfd2/signature.pgp From gary.jennejohn at freenet.de Tue Apr 7 02:13:38 2009 From: gary.jennejohn at freenet.de (Gary Jennejohn) Date: Tue Apr 7 02:14:39 2009 Subject: AMD 780G chipset major issues 3/3 (btx) In-Reply-To: <20090407095804.G8569@rust.salford.ac.uk> References: <83e5fb980904061402q73940f8at4ec4b8f821354320@mail.gmail.com> <200904062321.47691.thierry.herbelot@free.fr> <20090407095804.G8569@rust.salford.ac.uk> Message-ID: <20090407111218.0155d160@ernst.jennejohn.org> On Tue, 7 Apr 2009 09:59:16 +0100 (BST) "Mark Powell" wrote: > On Mon, 6 Apr 2009, Thierry Herbelot wrote: > > > Le Monday 06 April 2009, Diego Depaoli a __crit : > >> And finally... > >> if I enable ahci in bios the system won't boot with btx halted. > >> Ctrl+alt+del is the only allowed action. > >> > >> Yes... it's a low cost motherboard, but I'm a bit confused. > > > > My latest computer is also a 780G machine (running Stable, instead of > > current). > > Could we have some make/models guys? I'm interested in a new integrated > graphics MB for CURRENT and want to know what to avoid. > I have a Gigabyte GA-MA78GPM-DS2H (780G and AM2+) which works very well with -current and the radeonhd driver, including drm. I have the SATA disks running in AHCI mode. What does not work is a SATA DVD drive (seems to be a problem with the driver), so I'm using an IDE drive. I had to set hw.snd.default_unit=2 in /etc/sysctl.conf in order to get the front headphone port to work. --- Gary Jennejohn From max at love2party.net Tue Apr 7 02:15:32 2009 From: max at love2party.net (Max Laier) Date: Tue Apr 7 02:15:39 2009 Subject: AMD Opteron CPU PMC patch In-Reply-To: References: <4451ccf20904061110m91da3del8d39d81132a4dc48@mail.gmail.com> Message-ID: <200904071115.27975.max@love2party.net> On Tuesday 07 April 2009 11:03:42 Ivan Voras wrote: > ??ccuiyyan@sina.com wrote: > > Hi all : > > > > Are there any patches available in FreeBSD-current 8.0 for AMD > > Opteron CPU to support PMC? > > Ok, Google loses and you win. What is PMC? $ man pmc #FTW! ;) There is pmc.k{7,8} supporting K7/K8 Athlon processors. I find the AMD naming schemes confusing (at least) - so I'm not sure what you mean with "Opteron" in this context. -- /"\ Best regards, | mlaier@freebsd.org \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | mlaier@EFnet / \ ASCII Ribbon Campaign | Against HTML Mail and News From lists at c0mplx.org Tue Apr 7 02:21:08 2009 From: lists at c0mplx.org (Kurt Jaeger) Date: Tue Apr 7 02:21:22 2009 Subject: AMD 780G chipset major issues 3/3 (btx) In-Reply-To: <20090407111218.0155d160@ernst.jennejohn.org> References: <83e5fb980904061402q73940f8at4ec4b8f821354320@mail.gmail.com> <200904062321.47691.thierry.herbelot@free.fr> <20090407095804.G8569@rust.salford.ac.uk> <20090407111218.0155d160@ernst.jennejohn.org> Message-ID: <20090407092106.GA19850@home.opsec.eu> Hi! > > Could we have some make/models guys? I'm interested in a new integrated > > graphics MB for CURRENT and want to know what to avoid. I have an ASUS M4A78 PRO. CPU AMD Phenom(tm) II X4 810. OS: 7.2-PREREL, radeonhd works very nice. > I have the SATA disks running in AHCI mode. What does not work is > a SATA DVD drive (seems to be a problem with the driver), so I'm > using an IDE drive. Same here, SATA DVD is not detected. -- pi@opsec.eu +49 171 3101372 11 years to go ! From ivoras at freebsd.org Tue Apr 7 02:32:04 2009 From: ivoras at freebsd.org (Ivan Voras) Date: Tue Apr 7 02:32:11 2009 Subject: AMD Opteron CPU PMC patch In-Reply-To: <200904071115.27975.max@love2party.net> References: <4451ccf20904061110m91da3del8d39d81132a4dc48@mail.gmail.com> <200904071115.27975.max@love2party.net> Message-ID: Max Laier wrote: > On Tuesday 07 April 2009 11:03:42 Ivan Voras wrote: >> ??ccuiyyan@sina.com wrote: >>> Hi all : >>> >>> Are there any patches available in FreeBSD-current 8.0 for AMD >>> Opteron CPU to support PMC? >> Ok, Google loses and you win. What is PMC? > > $ man pmc #FTW! ;) /me bangs head against the wall. probable coffee deficiency. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 252 bytes Desc: OpenPGP digital signature Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20090407/c81d1cb1/signature-0001.pgp From tinderbox at freebsd.org Tue Apr 7 03:28:05 2009 From: tinderbox at freebsd.org (FreeBSD Tinderbox) Date: Tue Apr 7 03:28:12 2009 Subject: [head tinderbox] failure on ia64/ia64 Message-ID: <20090407102801.A32727302F@freebsd-current.sentex.ca> TB --- 2009-04-07 08:38:56 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2009-04-07 08:38:56 - starting HEAD tinderbox run for ia64/ia64 TB --- 2009-04-07 08:38:56 - cleaning the object tree TB --- 2009-04-07 08:39:33 - cvsupping the source tree TB --- 2009-04-07 08:39:33 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/ia64/ia64/supfile TB --- 2009-04-07 08:39:46 - building world TB --- 2009-04-07 08:39:46 - MAKEOBJDIRPREFIX=/obj TB --- 2009-04-07 08:39:46 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-04-07 08:39:46 - TARGET=ia64 TB --- 2009-04-07 08:39:46 - TARGET_ARCH=ia64 TB --- 2009-04-07 08:39:46 - TZ=UTC TB --- 2009-04-07 08:39:46 - __MAKE_CONF=/dev/null TB --- 2009-04-07 08:39:46 - cd /src TB --- 2009-04-07 08:39:46 - /usr/bin/make -B buildworld >>> World build started on Tue Apr 7 08:39:49 UTC 2009 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything [...] ===> usr.sbin/tzsetup (all) cc -O2 -pipe -I/src/usr.sbin/tzsetup -std=gnu99 -c /src/usr.sbin/tzsetup/tzsetup.c cc -O2 -pipe -I/src/usr.sbin/tzsetup -std=gnu99 -o tzsetup tzsetup.o -ldialog -lncurses gzip -cn /src/usr.sbin/tzsetup/tzsetup.8 > tzsetup.8.gz ===> usr.sbin/uathload (all) cc -O2 -pipe -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wunused-parameter -Wno-uninitialized -Wno-pointer-sign -c /src/usr.sbin/uathload/uathload.c ld -b binary -d -warn-common -r -d -o ar5523.o ar5523.bin ld: failed to merge target specific data of file ar5523.bin *** Error code 1 Stop in /src/usr.sbin/uathload. *** Error code 1 Stop in /src/usr.sbin. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-04-07 10:28:01 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-04-07 10:28:01 - ERROR: failed to build world TB --- 2009-04-07 10:28:01 - 5313.88 user 394.35 system 6545.36 real http://tinderbox.des.no/tinderbox-head-HEAD-ia64-ia64.full From ccuiyyan at gmail.com Mon Apr 6 23:32:16 2009 From: ccuiyyan at gmail.com (=?GB2312?B?tN7R0mNjdWl5eWFuQHNpbmEuY29t?=) Date: Tue Apr 7 04:22:17 2009 Subject: CPU hotplug Message-ID: <4451ccf20904062332y677d32a2q683d48c39762a857@mail.gmail.com> Dear all: Are there any methods to control the number of CPUs online or CPU hotplug in FreeBSD? I want to shutdown some CPUs in the experiments. Best Wishes! Yan From mister.olli at googlemail.com Tue Apr 7 04:42:05 2009 From: mister.olli at googlemail.com (Mister Olli) Date: Tue Apr 7 04:42:11 2009 Subject: Build XEN PV without WITNESS support Message-ID: <1239104515.18207.15.camel@phoenix.blechhirn.net> Hi list, building a XEN pv domU without WITNESS support, fails with the following error: In file included from /usr/src/sys/dev/xen/netfront/netfront.c:33: /usr/src/sys/sys/sx.h:210:2: error: #error "LOCK_DEBUG not defined, include before " mkdep: compile failed *** Error code 1 Stop in /usr/obj/usr/src/sys/freebsd8_WITHOUT_WITNESS. *** Error code 1 The bug has been acknowledged by Kip Macy in the beginning of february, but unfortunately it's not fixed in SVN yet. The appended patch does the fixing. Regards, Olli -------------- next part -------------- A non-text attachment was scrubbed... Name: LOCK_DEBUG.patch Type: text/x-patch Size: 320 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20090407/049a4577/LOCK_DEBUG.bin From barney_cordoba at yahoo.com Tue Apr 7 04:46:46 2009 From: barney_cordoba at yahoo.com (Barney Cordoba) Date: Tue Apr 7 04:46:52 2009 Subject: Syncing kernel module compilation Message-ID: <74059.39468.qm@web63904.mail.re1.yahoo.com> When I build a module in /sys/modules/MODULE the defines don't seem to be sync'd up with any particular kernel. Is there a method for building a single module without having to go into the kernel build directory and then traversing the deep module tree to get the one module I want to update? Barney From rwatson at FreeBSD.org Tue Apr 7 05:48:52 2009 From: rwatson at FreeBSD.org (Robert Watson) Date: Tue Apr 7 05:48:58 2009 Subject: Disabling CPUs at boot (was: Re: CPU hotplug) In-Reply-To: <4451ccf20904062332y677d32a2q683d48c39762a857@mail.gmail.com> References: <4451ccf20904062332y677d32a2q683d48c39762a857@mail.gmail.com> Message-ID: On Tue, 7 Apr 2009, $BVC4d(Jccuiyyan@sina.com wrote: > Are there any methods to control the number of CPUs online or CPU > hotplug in FreeBSD? > > I want to shutdown some CPUs in the experiments. Hi Yah: Currently, we really only support fully disabling CPUs at boot-time by forcing the CPU's local APIC not to probe: hint.lapic.X.disabled=1 Replace X with the CPU ID, I believe. And don't apply it to the boot processor. :-) Robert N M Watson Computer Laboratory University of Cambridge From M.S.Powell at salford.ac.uk Tue Apr 7 06:33:18 2009 From: M.S.Powell at salford.ac.uk (Mark Powell) Date: Tue Apr 7 06:33:25 2009 Subject: Apparently spurious ZFS CRC errors (was Re: ZFS data error without reasons) In-Reply-To: <20090326084726.N87213@rust.salford.ac.uk> References: <49BE4EC1.90207@163.com> <20090320102824.W75873@rust.salford.ac.uk> <20090320152737.D641@rust.salford.ac.uk> <20090325105613.55624rkkgf2xkr6s@webmail.leidinger.net> <20090325103721.G67233@rust.salford.ac.uk> <20090325135528.21416hzpozpjst8g@webmail.leidinger.net> <20090325125930.U73916@rust.salford.ac.uk> <20090325152128.2389990h7v6a02co@webmail.leidinger.net> <20090325152940.GB16409@cicely7.cicely.de> <20090325180054.L87213@rust.salford.ac.uk> <20090325183831.GD16409@cicely7.cicely.de> <20090326084726.N87213@rust.salford.ac.uk> Message-ID: <20090407142423.L31650@rust.salford.ac.uk> On Thu, 26 Mar 2009, Mark Powell wrote: > On Wed, 25 Mar 2009, Bernd Walter wrote: >> I don't know if it is with the drives, but other reasons are less >> likely in my opinion. >> The system is located in a data center and since I only get a few errors >> I decided to live with it and not to debug it further. > > I've decided to split my drives in two pools; 5x500GB RAIDZ1 of WD5000AAKS > and the 6x1TB RAIDZ2 of WD10EADS. I'll see if they perform differently. I'm > using the defaults of WC on, with all ZFS options enabled. Ok. I've been running with this config for 13 days now. During that time no CRC errors at all have been found on either pool. I have been scrubbing both pools together at 2am, hoping the simultaneous IO would cause some kind of hardware strain. There were again no CRC errors found in the scrub which occured at 2am today. However, after a few hours I see CRC errors appeared on both pools. Curiously CRC errors on both pools appeared at the same time. I've been running zpool status from cron every minute and all these new CRC errors, occured within two consecutive minutes: ----- # zpool status pool: pool state: ONLINE status: One or more devices has experienced an unrecoverable error. An attempt was made to correct the error. Applications are unaffected. action: Determine if the device needs to be replaced, and clear the errors using 'zpool clear' or replace the device with 'zpool replace'. see: http://www.sun.com/msg/ZFS-8000-9P scrub: scrub in progress for 0h11m, 6.16% done, 2h53m to go config: NAME STATE READ WRITE CKSUM pool ONLINE 0 0 0 raidz1 ONLINE 0 0 0 stripe/str0 ONLINE 0 0 0 ad8 ONLINE 0 0 0 ad10 ONLINE 0 0 0 ad12 ONLINE 0 0 0 ad14 ONLINE 0 0 1 errors: No known data errors pool: pool2 state: ONLINE status: One or more devices has experienced an unrecoverable error. An attempt was made to correct the error. Applications are unaffected. action: Determine if the device needs to be replaced, and clear the errors using 'zpool clear' or replace the device with 'zpool replace'. see: http://www.sun.com/msg/ZFS-8000-9P scrub: scrub in progress for 0h11m, 2.82% done, 6h29m to go config: NAME STATE READ WRITE CKSUM pool2 ONLINE 0 0 0 raidz2 ONLINE 0 0 0 ad18 ONLINE 0 0 0 ad20 ONLINE 0 0 4 ad22 ONLINE 0 0 2 ad24 ONLINE 0 0 0 ad26 ONLINE 0 0 0 ad28 ONLINE 0 0 6 errors: No known data errors ----- Is the opinion that this is still the drives? Cheers. -- Mark Powell - UNIX System Administrator - The University of Salford Information & Learning Services, Clifford Whitworth Building, Salford University, Manchester, M5 4WT, UK. Tel: +44 161 295 6843 Fax: +44 161 295 5888 www.pgp.com for PGP key From matheus at eternamente.info Tue Apr 7 06:34:14 2009 From: matheus at eternamente.info (Nenhum_de_Nos) Date: Tue Apr 7 06:34:20 2009 Subject: mplayer fails to build on current Message-ID: <104bdc11c08b1998f47241828d685db2.squirrel@cygnus.homeunix.com> hi, anyone else having problems too ? I've updated portsnap several times. I get this: gmake[1]: Entering directory `/usr/ports/multimedia/mplayer/work/MPlayer-1.0rc2/libavcodec' cc -O2 -pipe -O3 -ffast-math -fomit-frame-pointer -fno-strict-aliasing -I./libavcodec -I./libavformat -Wdisabled-optimization -Wno-pointer-sign -Wdeclaration-after-statement -I. -I. -I./libavutil -O2 -pipe -O3 -ffast-math -fomit-frame-pointer -fno-strict-aliasing -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE64_SOURCE -DHAVE_CONFIG_H -I/usr/local/include/freetype2 -I.. -I../libavutil -I/usr/local/include -I/usr/local/include -I/usr/local/include/freetype2 -I/usr/local/include -D_THREAD_SAFE -I/usr/local/include/gtk-2.0 -I/usr/local/lib/gtk-2.0/include -I/usr/local/include/atk-1.0 -I/usr/local/include/cairo -I/usr/local/include/pango-1.0 -I/usr/local/include -I/usr/local/include/glib-2.0 -I/usr/local/lib/glib-2.0/include -I/usr/local/include/pixman-1 -I/usr/local/include/freetype2 -I../libswscale -I../libavcodec -DBROKEN_RELOCATIONS -DHAVE_AV_CONFIG_H -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_ISOC9X_SOURCE -I.. -I.. -I../libavutil -Wdisabled-optimization -Wno-pointer-sign -Wdeclaration-after-statement -I. -I.. -I../libavutil -O2 -pipe -O3 -ffast-math -fomit-frame-pointer -fno-strict-aliasing -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE64_SOURCE -DHAVE_CONFIG_H -I/usr/local/include/freetype2 -I... -I.../libavutil -I/usr/local/include -I/usr/local/include -I/usr/local/include/freetype2 -I/usr/local/include -D_THREAD_SAFE -I/usr/local/include/gtk-2.0 -I/usr/local/lib/gtk-2.0/include -I/usr/local/include/atk-1.0 -I/usr/local/include/cairo -I/usr/local/include/pango-1.0 -I/usr/local/include -I/usr/local/include/glib-2.0 -I/usr/local/lib/glib-2.0/include -I/usr/local/include/pixman-1 -I/usr/local/include/freetype2 -c -o dsputil.o dsputil.c mpegvideo.h:777: error: nested function 'ff_get_mb_score' declared but never defined mpegvideo.h:775: error: nested function 'ff_epzs_motion_search' declared but never defined gmake[1]: *** [dsputil.o] Error 1 gmake[1]: Leaving directory `/usr/ports/multimedia/mplayer/work/MPlayer-1.0rc2/libavcodec' gmake: *** [libavcodec/libavcodec.a] Error 2 *** Error code 1 Stop in /usr/ports/multimedia/mplayer. *** Error code 1 FreeBSD xxx 8.0-CURRENT FreeBSD 8.0-CURRENT #2: Mon Mar 23 16:51:53 BRT 2009 xxx:/usr/obj/usr/src/sys/Core2Duo8 amd64 thanks, matheus -- We will call you cygnus, The God of balance you shall be From M.S.Powell at salford.ac.uk Tue Apr 7 06:38:26 2009 From: M.S.Powell at salford.ac.uk (Mark Powell) Date: Tue Apr 7 06:38:57 2009 Subject: Apparently spurious ZFS CRC errors (was Re: ZFS data error without reasons) In-Reply-To: <20090407142423.L31650@rust.salford.ac.uk> References: <49BE4EC1.90207@163.com> <20090320102824.W75873@rust.salford.ac.uk> <20090320152737.D641@rust.salford.ac.uk> <20090325105613.55624rkkgf2xkr6s@webmail.leidinger.net> <20090325103721.G67233@rust.salford.ac.uk> <20090325135528.21416hzpozpjst8g@webmail.leidinger.net> <20090325125930.U73916@rust.salford.ac.uk> <20090325152128.2389990h7v6a02co@webmail.leidinger.net> <20090325152940.GB16409@cicely7.cicely.de> <20090325180054.L87213@rust.salford.ac.uk> <20090325183831.GD16409@cicely7.cicely.de> <20090326084726.N87213@rust.salford.ac.uk> <20090407142423.L31650@rust.salford.ac.uk> Message-ID: <20090407143442.S31650@rust.salford.ac.uk> On Tue, 7 Apr 2009, Mark Powell wrote: > Curiously CRC errors on both pools appeared at the same time. I've been > running zpool status from cron every minute and all these new CRC errors, > occured within two consecutive minutes: Actually that was the status of a current scrub to see if the errors would go away. A zpool status from the time it occured: ----- Tue Apr 7 10:56:01 BST 2009 pool: pool state: ONLINE status: One or more devices has experienced an unrecoverable error. An attempt was made to correct the error. Applications are unaffected. action: Determine if the device needs to be replaced, and clear the errors using 'zpool clear' or replace the device with 'zpool replace'. see: http://www.sun.com/msg/ZFS-8000-9P scrub: scrub completed after 4h10m with 0 errors on Tue Apr 7 06:10:52 2009 config: NAME STATE READ WRITE CKSUM pool ONLINE 0 0 0 raidz1 ONLINE 0 0 0 stripe/str0 ONLINE 0 0 0 ad8 ONLINE 0 0 0 ad10 ONLINE 0 0 0 ad12 ONLINE 0 0 0 ad14 ONLINE 0 0 1 errors: No known data errors pool: pool2 state: ONLINE status: One or more devices has experienced an unrecoverable error. An attempt was made to correct the error. Applications are unaffected. action: Determine if the device needs to be replaced, and clear the errors using 'zpool clear' or replace the device with 'zpool replace'. see: http://www.sun.com/msg/ZFS-8000-9P scrub: scrub completed after 5h22m with 0 errors on Tue Apr 7 07:22:26 2009 config: NAME STATE READ WRITE CKSUM pool2 ONLINE 0 0 0 raidz2 ONLINE 0 0 0 ad18 ONLINE 0 0 0 ad20 ONLINE 0 0 4 ad22 ONLINE 0 0 2 ad24 ONLINE 0 0 0 ad26 ONLINE 0 0 0 ad28 ONLINE 0 0 6 errors: No known data errors ----- Cheers. -- Mark Powell - UNIX System Administrator - The University of Salford Information & Learning Services, Clifford Whitworth Building, Salford University, Manchester, M5 4WT, UK. Tel: +44 161 295 6843 Fax: +44 161 295 5888 www.pgp.com for PGP key From guru at unixarea.de Tue Apr 7 06:42:27 2009 From: guru at unixarea.de (Matthias Apitz) Date: Tue Apr 7 06:42:34 2009 Subject: mplayer fails to build on current In-Reply-To: <104bdc11c08b1998f47241828d685db2.squirrel@cygnus.homeunix.com> References: <104bdc11c08b1998f47241828d685db2.squirrel@cygnus.homeunix.com> Message-ID: <20090407134213.GA11982@rebelion.Sisis.de> El d?a Tuesday, April 07, 2009 a las 10:23:30AM -0300, Nenhum_de_Nos escribi?: > hi, > > anyone else having problems too ? > > I've updated portsnap several times. I get this: > > gmake[1]: Entering directory > `/usr/ports/multimedia/mplayer/work/MPlayer-1.0rc2/libavcodec' ... > -I/usr/local/include/pango-1.0 -I/usr/local/include > -I/usr/local/include/glib-2.0 -I/usr/local/lib/glib-2.0/include > -I/usr/local/include/pixman-1 -I/usr/local/include/freetype2 -c -o > dsputil.o dsputil.c > mpegvideo.h:777: error: nested function 'ff_get_mb_score' declared but > never defined > mpegvideo.h:775: error: nested function 'ff_epzs_motion_search' declared > but never defined > gmake[1]: *** [dsputil.o] Error 1 > gmake[1]: Leaving directory > `/usr/ports/multimedia/mplayer/work/MPlayer-1.0rc2/libavcodec' > gmake: *** [libavcodec/libavcodec.a] Error 2 > *** Error code 1 > > Stop in /usr/ports/multimedia/mplayer. > *** Error code 1 I run into the same problem and built it from SVN with: $ svn checkout svn://svn.mplayerhq.hu/mplayer/trunk mplayer $ ./configure ; make # make install matthias -- Matthias Apitz Manager Technical Support - OCLC GmbH Gruenwalder Weg 28g - 82041 Oberhaching - Germany t +49-89-61308 351 - f +49-89-61308 399 - m +49-170-4527211 e - w http://www.oclc.org/ http://www.UnixArea.de/ People who hate Microsoft Windows use Linux but people who love UNIX use FreeBSD. From matheus at eternamente.info Tue Apr 7 06:50:34 2009 From: matheus at eternamente.info (Nenhum_de_Nos) Date: Tue Apr 7 06:50:41 2009 Subject: mplayer fails to build on current In-Reply-To: <20090407134213.GA11982@rebelion.Sisis.de> References: <104bdc11c08b1998f47241828d685db2.squirrel@cygnus.homeunix.com> <20090407134213.GA11982@rebelion.Sisis.de> Message-ID: On Tue, April 7, 2009 10:42, Matthias Apitz wrote: > El d?a Tuesday, April 07, 2009 a las 10:23:30AM -0300, Nenhum_de_Nos > escribi?: > >> hi, >> >> anyone else having problems too ? >> >> I've updated portsnap several times. I get this: >> >> gmake[1]: Entering directory >> `/usr/ports/multimedia/mplayer/work/MPlayer-1.0rc2/libavcodec' > ... >> -I/usr/local/include/pango-1.0 -I/usr/local/include >> -I/usr/local/include/glib-2.0 -I/usr/local/lib/glib-2.0/include >> -I/usr/local/include/pixman-1 -I/usr/local/include/freetype2 -c -o >> dsputil.o dsputil.c >> mpegvideo.h:777: error: nested function 'ff_get_mb_score' declared but >> never defined >> mpegvideo.h:775: error: nested function 'ff_epzs_motion_search' declared >> but never defined >> gmake[1]: *** [dsputil.o] Error 1 >> gmake[1]: Leaving directory >> `/usr/ports/multimedia/mplayer/work/MPlayer-1.0rc2/libavcodec' >> gmake: *** [libavcodec/libavcodec.a] Error 2 >> *** Error code 1 >> >> Stop in /usr/ports/multimedia/mplayer. >> *** Error code 1 > > I run into the same problem and built it from SVN with: > > $ svn checkout svn://svn.mplayerhq.hu/mplayer/trunk mplayer > $ ./configure ; make > # make install > > matthias well, it's not just me. unresolved yet ? matheus -- We will call you cygnus, The God of balance you shall be From ale at FreeBSD.org Tue Apr 7 07:04:48 2009 From: ale at FreeBSD.org (Alex Dupre) Date: Tue Apr 7 07:04:55 2009 Subject: xorg loops In-Reply-To: <1238959921.1829.10.camel@balrog.2hip.net> References: <49D8D03B.8090302@arcor.de> <3a142e750904050919l1388b559t9bbd751546e239e7@mail.gmail.com> <1238957462.1829.8.camel@balrog.2hip.net> <49D90363.6010602@arcor.de> <1238959921.1829.10.camel@balrog.2hip.net> Message-ID: <49DB573C.3020703@FreeBSD.org> Robert Noland ha scritto: > hald should work fine with moused now. As you wrote in the UPDATING: "Use of AllowEmptyInput should no longer be needed for most users and moused should now work fine." I think "most" != "all" users, in fact my current up-to-date workstation still needs AllowEmptyInput to work. hal-device doesn't list any mouse at all. Is there anything I can do to help improving the situation? -- Alex Dupre From jhb at freebsd.org Tue Apr 7 07:29:00 2009 From: jhb at freebsd.org (John Baldwin) Date: Tue Apr 7 07:29:18 2009 Subject: Removal of GEOM_BSD, GEOM_MBR, GEOM_PC98 and GEOM_SUNLABEL In-Reply-To: <42E3BB6C-16C7-4211-A4FD-A362383418E9@mac.com> References: <09040423143118.91304@www.mmlab.cse.yzu.edu.tw> <42E3BB6C-16C7-4211-A4FD-A362383418E9@mac.com> Message-ID: <200904071019.44116.jhb@freebsd.org> On Saturday 04 April 2009 12:09:55 pm Marcel Moolenaar wrote: > > On Apr 4, 2009, at 8:16 AM, Tai-hwa Liang wrote: > > > I have to use ad0s7 after moving to GEOM_PART_{BSD,EBR,MBR}; > > otherwise, > > booting with with /dev/ad0s7a looks like: > > > Can't stat /dev/ad0s7a: No such file or directory > > It just hit me (doh!). The problem is that /dev/ad0s7 is a > compatibility symlink, which exists outside of the GEOM > graph. That is, it's a symlink that geom_dev creates and > it provides an alternate name to the same "entry point". > > In your case another GEOM (gpart for the BSD scheme) is > stacked onto the gpart GEOM for the EBR scheme) -- with > possibly other GEOMs in between. The provider for the 'a' > partition is named based on the underlying consumer, which > is based on the true name of the GEOM: "ad0s3+00103bf1a". > > There's no alias for the device node that corresponds to > this GEOM and based on some alias that was created by some > other geom_dev. This is simply not possible to without > messing things up pretty easily. > > In short: the solution of using a compatibility symlink is > flawed at best and useless in the worst case. > > There's no software fix for it. I think we're left with a > simple choice: > 1) have EBR create the "old" names and tell the user to > reboot every time they make a change in FreeBSD and when > booting into FreeBSD after the EBR changed, boot into > single user mode to change /etc/fstab and *then* go into > multi-user mode, or > 2) stick with the new names and tell the user to make this > one-time adjustment during upgrades and that's it. > > If we choose 2, we can argue whether to keep the symlinks > or not. I'm sure there's a small group of people for which > it works, but I fear the majority of people still have > problems. I think it is less painful for folks upgrading from 7 to just use the old names. It is also a lot easier on the eyes. I'm also not sure people are going to be changing their partition layout once it is done so having the names 'change' would not seem to be something that would happen very often at all in practice. -- John Baldwin From jhb at freebsd.org Tue Apr 7 07:29:04 2009 From: jhb at freebsd.org (John Baldwin) Date: Tue Apr 7 07:29:20 2009 Subject: missing atomic_exchg_*() in the atomic.h API ? In-Reply-To: <20090406083238.GB3358@onelab2.iet.unipi.it> References: <20090406083238.GB3358@onelab2.iet.unipi.it> Message-ID: <200904071024.07805.jhb@freebsd.org> On Monday 06 April 2009 4:32:38 am Luigi Rizzo wrote: > while looking at the functions in atomic.h i noticed that > there seems to be no atomic_exchg_*() in the API, though this > is a supported function in most/all supported archiectures, > and a useful function. We do have atomic_readandclear() which > uses the same underlying CPU instruction. > > Again, any objection if i add it ? Mostly b/c there hasn't been a need for it to date. I would probably spell out 'exchange' btw. -- John Baldwin From jhb at freebsd.org Tue Apr 7 07:29:05 2009 From: jhb at freebsd.org (John Baldwin) Date: Tue Apr 7 07:29:21 2009 Subject: AMD 780G chipset major issues 3/3 (btx) In-Reply-To: <83e5fb980904061402q73940f8at4ec4b8f821354320@mail.gmail.com> References: <83e5fb980904061402q73940f8at4ec4b8f821354320@mail.gmail.com> Message-ID: <200904071026.26735.jhb@freebsd.org> On Monday 06 April 2009 5:02:53 pm Diego Depaoli wrote: > And finally... > if I enable ahci in bios the system won't boot with btx halted. > Ctrl+alt+del is the only allowed action. > > Yes... it's a low cost motherboard, but I'm a bit confused. What OS release are you running? -- John Baldwin From m.e.sanliturk at gmail.com Tue Apr 7 07:59:21 2009 From: m.e.sanliturk at gmail.com (Mehmet Erol Sanliturk) Date: Tue Apr 7 07:59:28 2009 Subject: AMD 780G chipset major issues 3/3 (btx) In-Reply-To: <20090407095804.G8569@rust.salford.ac.uk> References: <83e5fb980904061402q73940f8at4ec4b8f821354320@mail.gmail.com> <200904062321.47691.thierry.herbelot@free.fr> <20090407095804.G8569@rust.salford.ac.uk> Message-ID: On Tue, Apr 7, 2009 at 4:59 AM, Mark Powell wrote: > On Mon, 6 Apr 2009, Thierry Herbelot wrote: > > Le Monday 06 April 2009, Diego Depaoli a ?crit : >> >>> And finally... >>> if I enable ahci in bios the system won't boot with btx halted. >>> Ctrl+alt+del is the only allowed action. >>> >>> Yes... it's a low cost motherboard, but I'm a bit confused. >>> >> >> My latest computer is also a 780G machine (running Stable, instead of >> current). >> > > Could we have some make/models guys? I'm interested in a new integrated > graphics MB for CURRENT and want to know what to avoid. > Cheers. > > -- > Mark Powell - UNIX System Administrator - The University of Salford > Information & Learning Services, Clifford Whitworth Building, > Salford University, Manchester, M5 4WT, UK. > Tel: +44 161 295 6843 Fax: +44 161 295 5888 www.pgp.com for PGP key > Some Linux distributions are requesting permission after an install to send a hardware profile to their official site . By collecting and using such profile values a data base may be constructed by FreeBSD . By studying that data base FreeBSD users may get information about next hardware selections . When an installation detects a problem about a hardware part it may also be sent to that data base to evaluate to its reasons . Hardware manufacturers may check that data base for possible utilization of data for their next product designs . That data base may be an incentive to hardware producers to support FreeBSD and be known by FreeBSD users . Thank you very much . Mehmet Erol Sanliturk From jrh29 at alumni.cwru.edu Tue Apr 7 08:15:49 2009 From: jrh29 at alumni.cwru.edu (Justin Hibbits) Date: Tue Apr 7 08:16:06 2009 Subject: AMD 780G chipset major issues 3/3 (btx) In-Reply-To: References: <83e5fb980904061402q73940f8at4ec4b8f821354320@mail.gmail.com> <200904062321.47691.thierry.herbelot@free.fr> <20090407095804.G8569@rust.salford.ac.uk> Message-ID: <20090407151628.GA46038@narn.knownspace> On Tue, Apr 07, 2009 at 10:59:17AM -0400, Mehmet Erol Sanliturk wrote: > Some Linux distributions are requesting permission after an install to send > a hardware profile to their official site . > > By collecting and using such profile values a data base may be constructed > by FreeBSD . > > By studying that data base FreeBSD users may get information about next > hardware selections . > > When an installation detects a problem about a hardware part it may also > be sent to that data base to evaluate to its reasons . > > Hardware manufacturers may check that data base for possible utilization > of data for their next product designs . > > That data base may be an incentive to hardware producers to support FreeBSD > and be known by FreeBSD users . > > Thank you very much . > > Mehmet Erol Sanliturk Look at sysutils/bsdstats. - Justin From gary.jennejohn at freenet.de Tue Apr 7 08:49:30 2009 From: gary.jennejohn at freenet.de (Gary Jennejohn) Date: Tue Apr 7 08:49:37 2009 Subject: AMD 780G chipset major issues 3/3 (btx) In-Reply-To: References: <83e5fb980904061402q73940f8at4ec4b8f821354320@mail.gmail.com> <200904062321.47691.thierry.herbelot@free.fr> <20090407095804.G8569@rust.salford.ac.uk> Message-ID: <20090407174927.117bfda8@ernst.jennejohn.org> On Tue, 7 Apr 2009 10:59:17 -0400 Mehmet Erol Sanliturk wrote: > On Tue, Apr 7, 2009 at 4:59 AM, Mark Powell wrote: > > > On Mon, 6 Apr 2009, Thierry Herbelot wrote: > > > > Le Monday 06 April 2009, Diego Depaoli a __crit : > >> > >>> And finally... > >>> if I enable ahci in bios the system won't boot with btx halted. > >>> Ctrl+alt+del is the only allowed action. > >>> > >>> Yes... it's a low cost motherboard, but I'm a bit confused. > >>> > >> > >> My latest computer is also a 780G machine (running Stable, instead of > >> current). > >> > > > > Could we have some make/models guys? I'm interested in a new integrated > > graphics MB for CURRENT and want to know what to avoid. > > Cheers. > > > > -- > > Mark Powell - UNIX System Administrator - The University of Salford > > Information & Learning Services, Clifford Whitworth Building, > > Salford University, Manchester, M5 4WT, UK. > > Tel: +44 161 295 6843 Fax: +44 161 295 5888 www.pgp.com for PGP key > > > > Some Linux distributions are requesting permission after an install to send > a hardware profile to their official site . > > By collecting and using such profile values a data base may be constructed > by FreeBSD . > There's already a mechanism for reporting working hardware - sendpr. However, it doesn't seem to be very useful. I reported that my motherboard supported FreeBSD really well on Nov 28, 2008. The PR is still marked as open. I suspect that, if the existing mechanism doesn't work, adding a new one won't work any better. --- Gary Jennejohn From m.e.sanliturk at gmail.com Tue Apr 7 09:21:26 2009 From: m.e.sanliturk at gmail.com (Mehmet Erol Sanliturk) Date: Tue Apr 7 09:21:33 2009 Subject: AMD 780G chipset major issues 3/3 (btx) In-Reply-To: <20090407174927.117bfda8@ernst.jennejohn.org> References: <83e5fb980904061402q73940f8at4ec4b8f821354320@mail.gmail.com> <200904062321.47691.thierry.herbelot@free.fr> <20090407095804.G8569@rust.salford.ac.uk> <20090407174927.117bfda8@ernst.jennejohn.org> Message-ID: On Tue, Apr 7, 2009 at 11:49 AM, Gary Jennejohn wrote: > On Tue, 7 Apr 2009 10:59:17 -0400 > Mehmet Erol Sanliturk wrote: > > > On Tue, Apr 7, 2009 at 4:59 AM, Mark Powell >wrote: > > > > > On Mon, 6 Apr 2009, Thierry Herbelot wrote: > > > > > > Le Monday 06 April 2009, Diego Depaoli a __crit : > > > > Some Linux distributions are requesting permission after an install to > send > > a hardware profile to their official site . > > > > By collecting and using such profile values a data base may be > constructed > > by FreeBSD . > > > > There's already a mechanism for reporting working hardware - sendpr. > > However, it doesn't seem to be very useful. > > I reported that my motherboard supported FreeBSD really well on Nov 28, > 2008. The PR is still marked as open. > > I suspect that, if the existing mechanism doesn't work, adding a new one > won't work any better. > > --- > Gary Jennejohn Look at sysutils/bsdstats. ( by Justin Hibbits ) You may see http://hcl.mandriva.com/ for what I mean for such a facility where http://www.bsdstats.org/ is not equivalent of the above Mandriva site . Thank you very much . Mehmet Erol Sanliturk From gelraen.ua at gmail.com Tue Apr 7 09:59:28 2009 From: gelraen.ua at gmail.com (Maxim Ignatenko) Date: Tue Apr 7 09:59:35 2009 Subject: mplayer fails to build on current In-Reply-To: <104bdc11c08b1998f47241828d685db2.squirrel@cygnus.homeunix.com> References: <104bdc11c08b1998f47241828d685db2.squirrel@cygnus.homeunix.com> Message-ID: > mpegvideo.h:777: error: nested function 'ff_get_mb_score' declared but > never defined > mpegvideo.h:775: error: nested function 'ff_epzs_motion_search' declared > but never defined > gmake[1]: *** [dsputil.o] Error 1 > gmake[1]: Leaving directory > `/usr/ports/multimedia/mplayer/work/MPlayer-1.0rc2/libavcodec' > gmake: *** [libavcodec/libavcodec.a] Error 2 > *** Error code 1 > > Stop in /usr/ports/multimedia/mplayer. > *** Error code 1 > > FreeBSD xxx 8.0-CURRENT FreeBSD 8.0-CURRENT #2: Mon Mar 23 16:51:53 BRT > 2009 xxx:/usr/obj/usr/src/sys/Core2Duo8 amd64 > Yeap, I had the same problem on CURRENT, and fixed it by removing "inline" keyword in 3 places (actually, before each declaration of problem functions in .h files). From xcllnt at mac.com Tue Apr 7 10:31:08 2009 From: xcllnt at mac.com (Marcel Moolenaar) Date: Tue Apr 7 10:39:24 2009 Subject: Root mount fails again. CAM related? Message-ID: <24C524FA-2D87-4A0E-97B7-4D7C832B3E72@mac.com> All, My ARM board boots from a USB mass storage device and for the second time the the root mount fails. First is was because the root mount wouldn't wait for the USB stack to complete the discovery process. Now CAM seems to have entered the picture: ... Timecounter "CPU Timer" frequency 166666667 Hz quality 1000 Timecounters tick every 10.000 msec usbus0: 480Mbps High Speed USB v2.0 WARNING: WITNESS option enabled, expect reduced performance. Root mount waiting for: usbus0 ugen0.1: at usbus0 uhub0: on usbus0 uhub0: 1 port with 1 removable, self powered Root mount waiting for: usbus0 ugen0.2: at usbus0 uhub1: on usbus0 Root mount waiting for: usbus0 uhub1: 7 ports with 7 removable, self powered Root mount waiting for: usbus0 ugen0.3: at usbus0 umass0: on usbus0 umass0: SCSI over Bulk-Only; quirks = 0x0000 Root mount waiting for: usbus0 umass0:0:0:-1: Attached to scbus0 Root mount waiting for: CAM Root mount waiting for: CAM Root mount waiting for: CAM Root mount waiting for: CAM Trying to mount root from ufs:/dev/da0p1 Manual root filesystem specification: : Mount using filesystem eg. ufs:/dev/da0a ? List valid disk boot devices Abort manual input There are no GEOMs at this point. Anyone else seeing this? -- Marcel Moolenaar xcllnt@mac.com From baptiste.daroussin at gmail.com Tue Apr 7 10:33:51 2009 From: baptiste.daroussin at gmail.com (Baptiste Daroussin) Date: Tue Apr 7 10:42:05 2009 Subject: mplayer fails to build on current In-Reply-To: References: <104bdc11c08b1998f47241828d685db2.squirrel@cygnus.homeunix.com> Message-ID: <20090407170815.GB78751@wicklow.lan> On Tue, Apr 07, 2009 at 07:59:26PM +0300, Maxim Ignatenko wrote: > > mpegvideo.h:777: error: nested function 'ff_get_mb_score' declared but > > never defined > > mpegvideo.h:775: error: nested function 'ff_epzs_motion_search' declared > > but never defined > > gmake[1]: *** [dsputil.o] Error 1 > > gmake[1]: Leaving directory > > `/usr/ports/multimedia/mplayer/work/MPlayer-1.0rc2/libavcodec' > > gmake: *** [libavcodec/libavcodec.a] Error 2 > > *** Error code 1 > > > > Stop in /usr/ports/multimedia/mplayer. > > *** Error code 1 > > > > FreeBSD xxx 8.0-CURRENT FreeBSD 8.0-CURRENT #2: Mon Mar 23 16:51:53 BRT > > 2009 xxx:/usr/obj/usr/src/sys/Core2Duo8 amd64 > > > > Yeap, I had the same problem on CURRENT, and fixed it by removing > "inline" keyword in 3 places (actually, before each declaration of > problem functions in .h files). Your version of current is to old, this problem has been resolved with this commit: http://freshbsd.org/2009/03/25/05/10/32 now it works fine regards Bapt From thierry.herbelot at free.fr Tue Apr 7 10:38:55 2009 From: thierry.herbelot at free.fr (Thierry Herbelot) Date: Tue Apr 7 10:46:35 2009 Subject: AMD 780G chipset major issues 3/3 (btx) In-Reply-To: <20090407111218.0155d160@ernst.jennejohn.org> References: <83e5fb980904061402q73940f8at4ec4b8f821354320@mail.gmail.com> <20090407095804.G8569@rust.salford.ac.uk> <20090407111218.0155d160@ernst.jennejohn.org> Message-ID: <200904071938.35626.thierry.herbelot@free.fr> Le Tuesday 07 April 2009, Gary Jennejohn a ?crit : > > I have a Gigabyte GA-MA78GPM-DS2H (780G and AM2+) which works very well > with -current and the radeonhd driver, including drm. My board must be the same : have you been able to add a PCI extension board ? (on my machine, I have added a second sound board, and it does even not show under the BIOS listing) > > I have the SATA disks running in AHCI mode. What does not work is > a SATA DVD drive (seems to be a problem with the driver), so I'm > using an IDE drive. I also cannot burn DVDs with the SATA drive TfH > > I had to set hw.snd.default_unit=2 in /etc/sysctl.conf in order to get the > front headphone port to work. > > --- > Gary Jennejohn > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" From pluknet at gmail.com Tue Apr 7 11:22:15 2009 From: pluknet at gmail.com (pluknet) Date: Tue Apr 7 11:22:22 2009 Subject: Root mount fails again. CAM related? In-Reply-To: <24C524FA-2D87-4A0E-97B7-4D7C832B3E72@mac.com> References: <24C524FA-2D87-4A0E-97B7-4D7C832B3E72@mac.com> Message-ID: 2009/4/7 Marcel Moolenaar : > All, > > My ARM board boots from a USB mass storage device and > for the second time the the root mount fails. First is > was because the root mount wouldn't wait for the USB > stack to complete the discovery process. Now CAM seems > to have entered the picture: > > ... > Timecounter "CPU Timer" frequency 166666667 Hz quality 1000 > Timecounters tick every 10.000 msec > usbus0: 480Mbps High Speed USB v2.0 > WARNING: WITNESS option enabled, expect reduced performance. > Root mount waiting for: usbus0 > ugen0.1: at usbus0 > uhub0: on usbus0 > uhub0: 1 port with 1 removable, self powered > Root mount waiting for: usbus0 > ugen0.2: at usbus0 > uhub1: 2> on usbus0 > Root mount waiting for: usbus0 > uhub1: 7 ports with 7 removable, self powered > Root mount waiting for: usbus0 > ugen0.3: at usbus0 > umass0: on > usbus0 > umass0: SCSI over Bulk-Only; quirks = 0x0000 > Root mount waiting for: usbus0 > umass0:0:0:-1: Attached to scbus0 > Root mount waiting for: CAM > Root mount waiting for: CAM > Root mount waiting for: CAM > Root mount waiting for: CAM > Trying to mount root from ufs:/dev/da0p1 > > Manual root filesystem specification: > : Mount using filesystem > eg. ufs:/dev/da0a > ? List valid disk boot devices > Abort manual input > > > There are no GEOMs at this point. > > Anyone else seeing this? > Can this be a similar one? That was committed not far ago in rev. 190676. http://lists.freebsd.org/pipermail/freebsd-current/2009-April/005635.html -- wbr, pluknet From xcllnt at mac.com Tue Apr 7 11:28:44 2009 From: xcllnt at mac.com (Marcel Moolenaar) Date: Tue Apr 7 11:28:51 2009 Subject: Root mount fails again. CAM related? In-Reply-To: References: <24C524FA-2D87-4A0E-97B7-4D7C832B3E72@mac.com> Message-ID: <74181BF8-E111-4208-8C3E-8F1B39808E0B@mac.com> On Apr 7, 2009, at 11:22 AM, pluknet wrote: >> My ARM board boots from a USB mass storage device and >> for the second time the the root mount fails. First is >> was because the root mount wouldn't wait for the USB >> stack to complete the discovery process. Now CAM seems >> to have entered the picture: >> > Can this be a similar one? That was committed not far ago in rev. > 190676. > http://lists.freebsd.org/pipermail/freebsd-current/2009-April/005635.html It could be the cause of the problem. Things worked fine before CAM grew calls to root_mount_hold()... -- Marcel Moolenaar xcllnt@mac.com From rbgarga at gmail.com Tue Apr 7 11:39:48 2009 From: rbgarga at gmail.com (Renato Botelho) Date: Tue Apr 7 11:39:54 2009 Subject: new usb: mass storage error, Synchronize cache failed Message-ID: <747dc8f30904071139j32b55e2pf0fcd07a51c260a2@mail.gmail.com> When I plug a gradiente cell phone on my USB I got this: Apr 7 15:33:01 botelhor root: Unknown USB device: vendor 0x0e8d product 0x0002 bus uhub0 Apr 7 15:33:01 botelhor kernel: ugen0.2: at usbus0 Apr 7 15:33:01 botelhor kernel: umass0: on usbus0 Apr 7 15:33:01 botelhor kernel: umass0: SCSI over Bulk-Only; quirks = 0x0000 Apr 7 15:33:02 botelhor kernel: umass0:0:0:-1: Attached to scbus0 Apr 7 15:33:02 botelhor kernel: da0 at umass-sim0 bus 0 target 0 lun 0 Apr 7 15:33:02 botelhor kernel: da0: Removable Direct Access SCSI-0 device Apr 7 15:33:02 botelhor kernel: da0: 1.000MB/s transfers Apr 7 15:33:02 botelhor kernel: da0: 982MB (2012160 512 byte sectors: 64H 32S/T 982C) Apr 7 15:33:02 botelhor kernel: da1 at umass-sim0 bus 0 target 0 lun 1 Apr 7 15:33:02 botelhor kernel: da1: Removable Direct Access SCSI-0 device Apr 7 15:33:02 botelhor kernel: da1: 1.000MB/s transfers Apr 7 15:33:02 botelhor kernel: da1: 1MB (3668 512 byte sectors: 64H 32S/T 1C) Apr 7 15:33:02 botelhor kernel: GEOM: da0: partition 1 does not start on a track boundary. Apr 7 15:33:02 botelhor kernel: GEOM: da0: partition 1 does not end on a track boundary. Apr 7 15:33:04 botelhor kernel: umass0: at uhub0, port 2, addr 2 (disconnected) Apr 7 15:33:04 botelhor kernel: (da1:umass-sim0:0:0:1): Synchronize cache failed, status == 0x3f, scsi status == 0x0 Apr 7 15:33:04 botelhor kernel: (da0:umass-sim0:0:0:0): lost device Apr 7 15:33:04 botelhor kernel: (da0:umass-sim0:0:0:0): removing device entry Apr 7 15:33:04 botelhor kernel: (da1:umass-sim0:0:0:1): lost device Apr 7 15:33:04 botelhor kernel: (da1:umass-sim0:0:0:1): removing device entry Apr 7 15:33:04 botelhor kernel: ugen0.2: at usbus0 (disconnected) Using 8.0-CURRENT r190550 I've tried on all usb ports, and have the same. Any idea? -- Renato Botelho From rnoland at FreeBSD.org Tue Apr 7 11:42:09 2009 From: rnoland at FreeBSD.org (Robert Noland) Date: Tue Apr 7 11:42:15 2009 Subject: xorg loops In-Reply-To: <49DB573C.3020703@FreeBSD.org> References: <49D8D03B.8090302@arcor.de> <3a142e750904050919l1388b559t9bbd751546e239e7@mail.gmail.com> <1238957462.1829.8.camel@balrog.2hip.net> <49D90363.6010602@arcor.de> <1238959921.1829.10.camel@balrog.2hip.net> <49DB573C.3020703@FreeBSD.org> Message-ID: <1239129677.1947.14.camel@balrog.2hip.net> On Tue, 2009-04-07 at 15:38 +0200, Alex Dupre wrote: > Robert Noland ha scritto: > > hald should work fine with moused now. > > As you wrote in the UPDATING: > > "Use of AllowEmptyInput should no longer > be needed for most users and moused should now work fine." > > I think "most" != "all" users, in fact my current up-to-date workstation > still needs AllowEmptyInput to work. hal-device doesn't list any mouse > at all. Is there anything I can do to help improving the situation? The root of the issue is that there are just too many ways to configure input devices... Particularly mice. Marcus, jkim and I have tried to make accommodations for all of the cases, but it gets rather tricky. Users can have mice configured using psm0, ums0, (serial even), moused and we have to be able to figure out if they are statically configured in X or not, based on whether or not X has already opened one of the file descriptors. Based on analyzing all of that, we decide whether or not to advertise to X that it should attach the device. If you are using moused, then hald *should* recognize that and advertise /dev/sysmouse to X. Additional input devices, get added via moused and hald knows that /dev/sysmouse is already opened by X, so it shouldn't re-advertise the same port again. We desperately need to simplify our input layer, but I'm not certain exactly what the right answer is. robert. -- Robert Noland FreeBSD -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 196 bytes Desc: This is a digitally signed message part Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20090407/1d843087/attachment.pgp From rnoland at FreeBSD.org Tue Apr 7 12:09:26 2009 From: rnoland at FreeBSD.org (Robert Noland) Date: Tue Apr 7 12:09:33 2009 Subject: Hal and KDM breakage (was Re: KDE4 and input events stalled) In-Reply-To: <20090407185915.GY31409@albert.catwhisker.org> References: <934e1d760904061455o4736d643o1d07e3292192d94c@mail.gmail.com> <1239057809.1908.2.camel@balrog.2hip.net> <49DAC742.8090507@freebsd.org> <1239075455.1908.36.camel@balrog.2hip.net> <49DACDBD.3030809@freebsd.org> <1239077210.1908.39.camel@balrog.2hip.net> <49DAD429.6090309@freebsd.org> <1239078081.1908.41.camel@balrog.2hip.net> <49DAE987.7090802@freebsd.org> <1239086408.35025.59.camel@shumai.marcuscom.com> <20090407185915.GY31409@albert.catwhisker.org> Message-ID: <1239131313.1947.18.camel@balrog.2hip.net> On Tue, 2009-04-07 at 11:59 -0700, David Wolfskill wrote: > On Tue, Apr 07, 2009 at 02:40:08AM -0400, Joe Marcus Clarke wrote: > > ... > > The problem is due to the fact that console-kit-daemon will not work if > > it starts up before init has started the ttys. Therefore, hald needs to > > come up after the getty processes have been spawned (i.e. after init has > > started the ttys). > > That would seem to contraindicate xdm (or similar) startup from > /etc/ttys, in general. > > > If the ttys were started as part of the rc.d process, this could be avoided. > > Hmmm.. > > > This is why GNOME makes people use the rc.d script to start gdm. It > > just won't work out of /etc/ttys. > > OK; I use xdm. And following what I thought was appropriate, I fired it > up out of /etc/ttys. > > I did, however, want to tweak things a bit; in particular, since I > regularly flip my laptop among stable/6, stable/7, and head, I wanted > the login screen to provide a hint as to what the machine was running at > the time. So I cobbled up a shell script to copy Xresources to an > appropriate place & apply sed(1) using selected output of uname(1). > > That's worked for ... well, years. > > But since hald(8) became involved in X, things got a bit ugly. > > In particular, it seemed that xdm was getting started before hald, and > that just wasn't helpful. At least with the above explanation, I'm > beginning to see why that is. > > I tweaked dependencies to force xdm to come up after hald, but even so, > that didn't help much: it seems that hald isn't really ready to provide > the services asked of it immediately. Note that it is dbus that needs to be active and working before something tries to start X... X will wait on hald for a bit. X will start up, register with dbus and ask for info from hald. If hald isn't up, or ready it will loop for a bit, waiting. Once hald is up and registers with dbus it will proceed. At least that is my recollection of how the code worked. robert. > So I hacked my xdm start-up script; it's got to the point where it seems > to work pretty reliaably for me; maybe it will help someone else: > > > #! /bin/sh > > # PROVIDE: xdm > # REQUIRE: hald dhclient moused ip_addr > # KEYWORD: nostart > > # This script is to be started from /etc/ttys, not /etc/rc. > > . /etc/rc.subr > > name="xdm" > > case "$1" in > start) > if ! hald=$(check_process hald-addon-mouse-sysmouse); then > sleep 5 > exit 1 > fi > if [ ! -r /proc/${hald}/status ]; then > sleep 5 > exit 1 > fi > hald_start=`awk -F "[ ,]" '{print $8}' /proc/${hald}/status` > now=`date "+%s"` > # This was determined empirically > hald_delay=8 > wait=$(($hald_start + $hald_delay - $now)) > if [ $wait -gt 0 ]; then > info "$name start-up waiting $wait seconds for hald-addon-mouse-sysmouse" > sleep $wait > fi > if [ -x /usr/local/bin/xdm ]; then > old_dir=/usr/local/lib/X11/xdm > new_dir=`/usr/bin/mktemp -d /tmp/.xdm-XXXXX` > uname=`uname -v | sed -e "s/ .*$//"` > sed -e "s/ Welcome to CLIENTHOST/ CLIENTHOST - ${uname}/" \ > -e "/greetFont/s/24-240/18-180/" \ > -e "s/Serif-24/Serif-18/" \ > ${old_dir}/Xresources >${new_dir}/Xresources > /usr/local/bin/xdm -nodaemon -resources "${new_dir}/Xresources" > fi > info "Starting ${name}." > ;; > stop) > [ -r /var/run/xdm.pid ] && \ > kill `cat /var/run/xdm.pid` && \ > rm -fr /tmp/.xdm-????? && \ > info -n ' xdm' > ;; > restart) > $0 stop; $0 start > ;; > *) > err 1 "Usage: `basename $0` {start|stop}|restart" > ;; > esac > > exit 0 > > > [I originally tried merely sleeping a bit, but eventually found it more > reliable to merely exit the script & let init(8) re-spawn it.) > > Peace, > david -- Robert Noland FreeBSD -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 196 bytes Desc: This is a digitally signed message part Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20090407/d0e660fb/attachment.pgp From ggajic at afrodita.rcub.bg.ac.yu Tue Apr 7 11:38:15 2009 From: ggajic at afrodita.rcub.bg.ac.yu (Goran Gajic) Date: Tue Apr 7 12:12:45 2009 Subject: Root mount waiting for... Message-ID: Today I have svn up from r190569 to r190813, did make buildworld and recompiled kernel. System boots normaly, but when root file system should be mounted I see this message: Root mount waiting for: and some silly symbols after that. This keeps repating.. Here is my dmesg from working kernel from r190469: Copyright (c) 1992-2009 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 is a registered trademark of The FreeBSD Foundation. FreeBSD 8.0-CURRENT #0 r190569: Mon Mar 30 21:16:41 CEST 2009 root@magarac:/usr/src/sys/amd64/compile/GENERIC WARNING: WITNESS option enabled, expect reduced performance. Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel(R) Core(TM)2 Quad CPU Q8200 @ 2.33GHz (2333.08-MHz K8-class CPU) Origin = "GenuineIntel" Id = 0x10677 Stepping = 7 Features=0xbfebfbff Features2=0x8e39d AMD Features=0x20100800 AMD Features2=0x1 TSC: P-state invariant Cores per package: 4 usable memory = 3204370432 (3055 MB) avail memory = 3097583616 (2954 MB) ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 cpu2 (AP): APIC ID: 2 cpu3 (AP): APIC ID: 3 ioapic0 irqs 0-23 on motherboard kbd1 at kbdmux0 acpi0: on motherboard acpi0: [ITHREAD] acpi0: Power Button (fixed) acpi0: reservation of 0, a0000 (3) failed acpi0: reservation of 100000, bff00000 (3) failed Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x808-0x80b on acpi0 acpi_hpet0: iomem 0xfed00000-0xfed003ff on acpi0 Timecounter "HPET" frequency 14318180 Hz quality 900 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pcib1: irq 16 at device 1.0 on pci0 pci1: on pcib1 vgapci0: port 0xa000-0xa0ff mem 0xd0000000-0xdfffffff,0xfbae0000-0xfbaeffff irq 16 at device 0.0 on pci1 pci1: at device 0.1 (no driver attached) uhci0: port 0x9800-0x981f irq 16 at device 26.0 on pci0 uhci0: [ITHREAD] uhci0: LegSup = 0x0f30 usbus0: on uhci0 uhci1: port 0x9880-0x989f irq 21 at device 26.1 on pci0 uhci1: [ITHREAD] uhci1: LegSup = 0x0f30 usbus1: on uhci1 uhci2: port 0x9c00-0x9c1f irq 18 at device 26.2 on pci0 uhci2: [ITHREAD] uhci2: LegSup = 0x0f30 usbus2: on uhci2 ehci0: mem 0xfb9ffc00-0xfb9fffff irq 18 at device 26.7 on pci0 ehci0: [ITHREAD] usbus3: EHCI version 1.0 usbus3: on ehci0 pci0: at device 27.0 (no driver attached) pcib2: irq 17 at device 28.0 on pci0 pci5: on pcib2 pcib3: at device 0.0 on pci5 pci7: on pcib3 amr0: mem 0xfaff0000-0xfaffffff irq 18 at device 2.0 on pci7 amr0: Using 64-bit DMA amr0: [ITHREAD] amr0: delete logical drives supported by controller amr0: Firmware 352D, BIOS 1.10, 64MB RAM pcib4: mem 0xfbeffc00-0xfbeffc7f irq 16 at device 0.1 on pci5 pci6: on pcib4 pcib5: irq 18 at device 28.2 on pci0 pci4: on pcib5 mskc0: port 0xd800-0xd8ff mem 0xfbdfc000-0xfbdfffff irq 18 at device 0.0 on pci4 msk0: on mskc0 msk0: Ethernet address: 00:1d:60:c9:1a:3e miibus0: on msk0 e1000phy0: PHY 0 on miibus0 e1000phy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseTX-FDX, auto mskc0: [FILTER] pcib6: irq 19 at device 28.3 on pci0 pci3: on pcib6 mskc1: port 0xc800-0xc8ff mem 0xfbcfc000-0xfbcfffff irq 19 at device 0.0 on pci3 msk1: on mskc1 msk1: Ethernet address: 00:1d:60:c9:17:a3 miibus1: on msk1 e1000phy1: PHY 0 on miibus1 e1000phy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseTX-FDX, auto mskc1: [FILTER] pcib7: irq 17 at device 28.4 on pci0 pci2: on pcib7 atapci0: port 0xbc00-0xbc07,0xb880-0xb883,0xb800-0xb807,0xb480-0xb483,0xb400-0xb40f mem 0xfbbffc00-0xfbbfffff irq 16 at device 0.0 on pci2 atapci0: [ITHREAD] ata2: on atapci0 ata2: [ITHREAD] ata3: on atapci0 ata3: [ITHREAD] uhci3: port 0x9080-0x909f irq 23 at device 29.0 on pci0 uhci3: [ITHREAD] uhci3: LegSup = 0x0f30 usbus4: on uhci3 uhci4: port 0x9400-0x941f irq 19 at device 29.1 on pci0 uhci4: [ITHREAD] uhci4: LegSup = 0x0f30 usbus5: on uhci4 uhci5: port 0x9480-0x949f irq 18 at device 29.2 on pci0 uhci5: [ITHREAD] uhci5: LegSup = 0x0f30 usbus6: on uhci5 ehci1: mem 0xfb9ff800-0xfb9ffbff irq 23 at device 29.7 on pci0 ehci1: [ITHREAD] usbus7: EHCI version 1.0 usbus7: on ehci1 pcib8: at device 30.0 on pci0 pci8: on pcib8 pci8: at device 0.0 (no driver attached) pci8: at device 0.2 (no driver attached) fwohci0: port 0xec00-0xec7f mem 0xfebff800-0xfebfffff irq 19 at device 3.0 on pci8 fwohci0: [ITHREAD] fwohci0: OHCI version 1.10 (ROM=1) fwohci0: No. of Isochronous channels is 4. fwohci0: EUI64 00:11:d8:00:01:8a:3e:e5 fwohci0: Phy 1394a available S400, 2 ports. fwohci0: Link S400, max_rec 2048 bytes. firewire0: on fwohci0 dcons_crom0: on firewire0 dcons_crom0: bus_addr 0x147c000 fwe0: on firewire0 if_fwe0: Fake Ethernet address: 02:11:d8:8a:3e:e5 fwe0: Ethernet address: 02:11:d8:8a:3e:e5 fwip0: on firewire0 fwip0: Firewire address: 00:11:d8:00:01:8a:3e:e5 @ 0xfffe00000000, S400, maxrec 2048 sbp0: on firewire0 fwohci0: Initiate bus reset fwohci0: fwohci_intr_core: BUS reset fwohci0: fwohci_intr_core: node_id=0x00000000, SelfID Count=1, CYCLEMASTER mode isab0: at device 31.0 on pci0 isa0: on isab0 atapci1: port 0x8000-0x8007,0x7c00-0x7c03,0x7880-0x7887,0x7800-0x7803,0x7480-0x748f,0x7400-0x740f irq 22 at device 31.2 on pci0 atapci1: [ITHREAD] ata4: on atapci1 ata4: [ITHREAD] ata5: on atapci1 ata5: [ITHREAD] pci0: at device 31.3 (no driver attached) atapci2: port 0x9000-0x9007,0x8c00-0x8c03,0x8880-0x8887,0x8800-0x8803,0x8480-0x848f,0x8400-0x840f irq 22 at device 31.5 on pci0 atapci2: [ITHREAD] ata6: on atapci2 ata6: [ITHREAD] ata7: on atapci2 ata7: [ITHREAD] acpi_button0: on acpi0 atrtc0: port 0x70-0x71 irq 8 on acpi0 fdc0: port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on acpi0 fdc0: [FILTER] fd0: <1440-KB 3.5" drive> on fdc0 drive 0 uart0: <16550 or compatible> port 0x3f8-0x3ff irq 4 on acpi0 uart0: [FILTER] atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] atkbd0: [ITHREAD] cpu0: on acpi0 ACPI Warning (tbutils-0243): Incorrect checksum in table [OEMB] - 8D, should be 84 [20070320] est0: on cpu0 p4tcc0: on cpu0 cpu1: on acpi0 est1: on cpu1 p4tcc1: on cpu1 cpu2: on acpi0 est2: on cpu2 p4tcc2: on cpu2 cpu3: on acpi0 est3: on cpu3 p4tcc3: on cpu3 orm0: at iomem 0xc0000-0xcffff on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 ata0 at port 0x1f0-0x1f7,0x3f6 irq 14 on isa0 ata0: [ITHREAD] ata1 at port 0x170-0x177,0x376 irq 15 on isa0 ata1: [ITHREAD] ppc0: cannot reserve I/O port range Timecounters tick every 1.000 msec firewire0: 1 nodes, maxhop <= 0 cable IRM irm(0) (me) firewire0: bus manager 0 usbus7: 480Mbps High Speed USB v2.0 usbus0: 12Mbps Full Speed USB v1.0 usbus1: 12Mbps Full Speed USB v1.0 usbus2: 12Mbps Full Speed USB v1.0 usbus3: 480Mbps High Speed USB v2.0 usbus4: 12Mbps Full Speed USB v1.0 usbus5: 12Mbps Full Speed USB v1.0 usbus6: 12Mbps Full Speed USB v1.0 acd0: DVDR at ata2-master UDMA33 amr0: delete logical drives supported by controller amrd0: on amr0 amrd0: 209640MB (429342720 sectors) RAID 0 (optimal) ugen7.1: at usbus7 uhub0: on usbus7 ugen0.1: at usbus0 uhub1: on usbus0 ugen1.1: at usbus1 uhub2: on usbus1 ugen2.1: at usbus2 uhub3: on usbus2 ugen3.1: at usbus3 uhub4: on usbus3 ugen4.1: at usbus4 uhub5: on usbus4 ugen5.1: at usbus5 uhub6: on usbus5 ugen6.1: at usbus6 uhub7: on usbus6 uhub1: 2 ports with 2 removable, self powered uhub2: 2 ports with 2 removable, self powered uhub3: 2 ports with 2 removable, self powered uhub5: 2 ports with 2 removable, self powered uhub6: 2 ports with 2 removable, self powered uhub7: 2 ports with 2 removable, self powered GEOM_LABEL: Label for provider amrd0s2a is ufsid/493083c65bf6e03f. GEOM_LABEL: Label for provider amrd0s2d is ufsid/493083c849b0f9c2. GEOM_LABEL: Label for provider amrd0s2e is ufsid/493083ca68aa5442. GEOM_LABEL: Label for provider amrd0s2f is ufsid/493083cb11d37e10. GEOM_LABEL: Label for provider amrd0s2g is ufsid/493083cd2b0c975c. uhub0: 6 ports with 6 removable, self powered uhub4: 6 ports with 6 removable, self powered ugen6.2: at usbus6 ums0: on usbus6 ums0: 3 buttons and [XYZ] coordinates SMP: AP CPU #1 Launched! SMP: AP CPU #2 Launched! SMP: AP CPU #3 Launched! WARNING: WITNESS option enabled, expect reduced performance. Trying to mount root from ufs:/dev/amrd0s2a GEOM_LABEL: Label ufsid/493083c65bf6e03f removed. GEOM_LABEL: Label for provider amrd0s2a is ufsid/493083c65bf6e03f. GEOM_LABEL: Label ufsid/493083c849b0f9c2 removed. GEOM_LABEL: Label for provider amrd0s2d is ufsid/493083c849b0f9c2. GEOM_LABEL: Label ufsid/493083ca68aa5442 removed. GEOM_LABEL: Label for provider amrd0s2e is ufsid/493083ca68aa5442. GEOM_LABEL: Label ufsid/493083cb11d37e10 removed. GEOM_LABEL: Label for provider amrd0s2f is ufsid/493083cb11d37e10. GEOM_LABEL: Label ufsid/493083cd2b0c975c removed. GEOM_LABEL: Label for provider amrd0s2g is ufsid/493083cd2b0c975c. GEOM_LABEL: Label ufsid/493083c65bf6e03f removed. GEOM_LABEL: Label ufsid/493083c849b0f9c2 removed. GEOM_LABEL: Label ufsid/493083ca68aa5442 removed. GEOM_LABEL: Label ufsid/493083cb11d37e10 removed. GEOM_LABEL: Label ufsid/493083cd2b0c975c removed. lock order reversal: 1st 0xfffffffe7e25b180 bufwait (bufwait) @ kern/vfs_bio.c:2549 2nd 0xffffff0001cecc00 dirhash (dirhash) @ ufs/ufs/ufs_dirhash.c:275 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2a _witness_debugger() at _witness_debugger+0x2e witness_checkorder() at witness_checkorder+0x81e _sx_xlock() at _sx_xlock+0x55 ufsdirhash_acquire() at ufsdirhash_acquire+0x33 ufsdirhash_add() at ufsdirhash_add+0x19 ufs_direnter() at ufs_direnter+0x88b ufs_mkdir() at ufs_mkdir+0x633 VOP_MKDIR_APV() at VOP_MKDIR_APV+0x93 kern_mkdirat() at kern_mkdirat+0x2b2 syscall() at syscall+0x1bf Xfast_syscall() at Xfast_syscall+0xab --- syscall (136, FreeBSD ELF64, mkdir), rip = 0x80071ed4c, rsp = 0x7fffffffec98, rbp = 0x7fffffffef6e --- KLD snd_hda.ko: depends on kernel - not available linker_load_file: Unsupported file type KLD linux.ko: depends on kernel - not available linker_load_file: Unsupported file type msk0: link state changed to UP Best regards, gg. From david at catwhisker.org Tue Apr 7 12:21:49 2009 From: david at catwhisker.org (David Wolfskill) Date: Tue Apr 7 12:21:57 2009 Subject: Hal and KDM breakage (was Re: KDE4 and input events stalled) In-Reply-To: <1239086408.35025.59.camel@shumai.marcuscom.com> References: <934e1d760904061455o4736d643o1d07e3292192d94c@mail.gmail.com> <1239057809.1908.2.camel@balrog.2hip.net> <49DAC742.8090507@freebsd.org> <1239075455.1908.36.camel@balrog.2hip.net> <49DACDBD.3030809@freebsd.org> <1239077210.1908.39.camel@balrog.2hip.net> <49DAD429.6090309@freebsd.org> <1239078081.1908.41.camel@balrog.2hip.net> <49DAE987.7090802@freebsd.org> <1239086408.35025.59.camel@shumai.marcuscom.com> Message-ID: <20090407185915.GY31409@albert.catwhisker.org> On Tue, Apr 07, 2009 at 02:40:08AM -0400, Joe Marcus Clarke wrote: > ... > The problem is due to the fact that console-kit-daemon will not work if > it starts up before init has started the ttys. Therefore, hald needs to > come up after the getty processes have been spawned (i.e. after init has > started the ttys). That would seem to contraindicate xdm (or similar) startup from /etc/ttys, in general. > If the ttys were started as part of the rc.d process, this could be avoided. Hmmm.. > This is why GNOME makes people use the rc.d script to start gdm. It > just won't work out of /etc/ttys. OK; I use xdm. And following what I thought was appropriate, I fired it up out of /etc/ttys. I did, however, want to tweak things a bit; in particular, since I regularly flip my laptop among stable/6, stable/7, and head, I wanted the login screen to provide a hint as to what the machine was running at the time. So I cobbled up a shell script to copy Xresources to an appropriate place & apply sed(1) using selected output of uname(1). That's worked for ... well, years. But since hald(8) became involved in X, things got a bit ugly. In particular, it seemed that xdm was getting started before hald, and that just wasn't helpful. At least with the above explanation, I'm beginning to see why that is. I tweaked dependencies to force xdm to come up after hald, but even so, that didn't help much: it seems that hald isn't really ready to provide the services asked of it immediately. So I hacked my xdm start-up script; it's got to the point where it seems to work pretty reliaably for me; maybe it will help someone else: #! /bin/sh # PROVIDE: xdm # REQUIRE: hald dhclient moused ip_addr # KEYWORD: nostart # This script is to be started from /etc/ttys, not /etc/rc. . /etc/rc.subr name="xdm" case "$1" in start) if ! hald=$(check_process hald-addon-mouse-sysmouse); then sleep 5 exit 1 fi if [ ! -r /proc/${hald}/status ]; then sleep 5 exit 1 fi hald_start=`awk -F "[ ,]" '{print $8}' /proc/${hald}/status` now=`date "+%s"` # This was determined empirically hald_delay=8 wait=$(($hald_start + $hald_delay - $now)) if [ $wait -gt 0 ]; then info "$name start-up waiting $wait seconds for hald-addon-mouse-sysmouse" sleep $wait fi if [ -x /usr/local/bin/xdm ]; then old_dir=/usr/local/lib/X11/xdm new_dir=`/usr/bin/mktemp -d /tmp/.xdm-XXXXX` uname=`uname -v | sed -e "s/ .*$//"` sed -e "s/ Welcome to CLIENTHOST/ CLIENTHOST - ${uname}/" \ -e "/greetFont/s/24-240/18-180/" \ -e "s/Serif-24/Serif-18/" \ ${old_dir}/Xresources >${new_dir}/Xresources /usr/local/bin/xdm -nodaemon -resources "${new_dir}/Xresources" fi info "Starting ${name}." ;; stop) [ -r /var/run/xdm.pid ] && \ kill `cat /var/run/xdm.pid` && \ rm -fr /tmp/.xdm-????? && \ info -n ' xdm' ;; restart) $0 stop; $0 start ;; *) err 1 "Usage: `basename $0` {start|stop}|restart" ;; esac exit 0 [I originally tried merely sleeping a bit, but eventually found it more reliable to merely exit the script & let init(8) re-spawn it.) Peace, david -- David H. Wolfskill david@catwhisker.org Depriving a girl or boy of an opportunity for education is evil. See http://www.catwhisker.org/~david/publickey.gpg for my public key. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20090407/d2162379/attachment.pgp From rnoland at FreeBSD.org Tue Apr 7 12:23:35 2009 From: rnoland at FreeBSD.org (Robert Noland) Date: Tue Apr 7 12:23:41 2009 Subject: AMD 780G chipset major issues 3/3 (btx) In-Reply-To: <20090407095804.G8569@rust.salford.ac.uk> References: <83e5fb980904061402q73940f8at4ec4b8f821354320@mail.gmail.com> <200904062321.47691.thierry.herbelot@free.fr> <20090407095804.G8569@rust.salford.ac.uk> Message-ID: <1239132158.1947.21.camel@balrog.2hip.net> On Tue, 2009-04-07 at 09:59 +0100, Mark Powell wrote: > On Mon, 6 Apr 2009, Thierry Herbelot wrote: > > > Le Monday 06 April 2009, Diego Depaoli a ?crit : > >> And finally... > >> if I enable ahci in bios the system won't boot with btx halted. > >> Ctrl+alt+del is the only allowed action. > >> > >> Yes... it's a low cost motherboard, but I'm a bit confused. > > > > My latest computer is also a 780G machine (running Stable, instead of > > current). > > Could we have some make/models guys? I'm interested in a new integrated > graphics MB for CURRENT and want to know what to avoid. > Cheers. I can't really speak for the other components, but afaik, all of the radeon IGPs should be working ok. I think it is an 780G that AMD is planning to send me once it gets approved as well... robert. > -- > Mark Powell - UNIX System Administrator - The University of Salford > Information & Learning Services, Clifford Whitworth Building, > Salford University, Manchester, M5 4WT, UK. > Tel: +44 161 295 6843 Fax: +44 161 295 5888 www.pgp.com for PGP key > _______________________________________________ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" -- Robert Noland FreeBSD -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 196 bytes Desc: This is a digitally signed message part Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20090407/4083f31d/attachment-0001.pgp From marcus at freebsd.org Tue Apr 7 12:25:26 2009 From: marcus at freebsd.org (Joe Marcus Clarke) Date: Tue Apr 7 12:25:34 2009 Subject: Hal and KDM breakage (was Re: KDE4 and input events stalled) In-Reply-To: <20090407185915.GY31409@albert.catwhisker.org> References: <934e1d760904061455o4736d643o1d07e3292192d94c@mail.gmail.com> <1239057809.1908.2.camel@balrog.2hip.net> <49DAC742.8090507@freebsd.org> <1239075455.1908.36.camel@balrog.2hip.net> <49DACDBD.3030809@freebsd.org> <1239077210.1908.39.camel@balrog.2hip.net> <49DAD429.6090309@freebsd.org> <1239078081.1908.41.camel@balrog.2hip.net> <49DAE987.7090802@freebsd.org> <1239086408.35025.59.camel@shumai.marcuscom.com> <20090407185915.GY31409@albert.catwhisker.org> Message-ID: <49DBA371.3080804@freebsd.org> David Wolfskill wrote: > On Tue, Apr 07, 2009 at 02:40:08AM -0400, Joe Marcus Clarke wrote: >> ... >> The problem is due to the fact that console-kit-daemon will not work if >> it starts up before init has started the ttys. Therefore, hald needs to >> come up after the getty processes have been spawned (i.e. after init has >> started the ttys). > > That would seem to contraindicate xdm (or similar) startup from > /etc/ttys, in general. > >> If the ttys were started as part of the rc.d process, this could be avoided. > > Hmmm.. > >> This is why GNOME makes people use the rc.d script to start gdm. It >> just won't work out of /etc/ttys. > > OK; I use xdm. And following what I thought was appropriate, I fired it > up out of /etc/ttys. > > I did, however, want to tweak things a bit; in particular, since I > regularly flip my laptop among stable/6, stable/7, and head, I wanted > the login screen to provide a hint as to what the machine was running at > the time. So I cobbled up a shell script to copy Xresources to an > appropriate place & apply sed(1) using selected output of uname(1). > > That's worked for ... well, years. > > But since hald(8) became involved in X, things got a bit ugly. > > In particular, it seemed that xdm was getting started before hald, and > that just wasn't helpful. At least with the above explanation, I'm > beginning to see why that is. > > I tweaked dependencies to force xdm to come up after hald, but even so, > that didn't help much: it seems that hald isn't really ready to provide > the services asked of it immediately. > > So I hacked my xdm start-up script; it's got to the point where it seems > to work pretty reliaably for me; maybe it will help someone else: > > > #! /bin/sh > > # PROVIDE: xdm > # REQUIRE: hald dhclient moused ip_addr > # KEYWORD: nostart > > # This script is to be started from /etc/ttys, not /etc/rc. > > . /etc/rc.subr > > name="xdm" > > case "$1" in > start) > if ! hald=$(check_process hald-addon-mouse-sysmouse); then > sleep 5 > exit 1 > fi > if [ ! -r /proc/${hald}/status ]; then > sleep 5 > exit 1 > fi > hald_start=`awk -F "[ ,]" '{print $8}' /proc/${hald}/status` > now=`date "+%s"` > # This was determined empirically > hald_delay=8 > wait=$(($hald_start + $hald_delay - $now)) > if [ $wait -gt 0 ]; then > info "$name start-up waiting $wait seconds for hald-addon-mouse-sysmouse" > sleep $wait > fi > if [ -x /usr/local/bin/xdm ]; then > old_dir=/usr/local/lib/X11/xdm > new_dir=`/usr/bin/mktemp -d /tmp/.xdm-XXXXX` > uname=`uname -v | sed -e "s/ .*$//"` > sed -e "s/ Welcome to CLIENTHOST/ CLIENTHOST - ${uname}/" \ > -e "/greetFont/s/24-240/18-180/" \ > -e "s/Serif-24/Serif-18/" \ > ${old_dir}/Xresources >${new_dir}/Xresources > /usr/local/bin/xdm -nodaemon -resources "${new_dir}/Xresources" > fi > info "Starting ${name}." > ;; > stop) > [ -r /var/run/xdm.pid ] && \ > kill `cat /var/run/xdm.pid` && \ > rm -fr /tmp/.xdm-????? && \ > info -n ' xdm' > ;; > restart) > $0 stop; $0 start > ;; > *) > err 1 "Usage: `basename $0` {start|stop}|restart" > ;; > esac > > exit 0 > > > [I originally tried merely sleeping a bit, but eventually found it more > reliable to merely exit the script & let init(8) re-spawn it.) See /usr/ports/x11/gdm/files/gdm.in. This is working for GNOME users. Joe -- Joe Marcus Clarke FreeBSD GNOME Team :: gnome@FreeBSD.org FreeNode / #freebsd-gnome http://www.FreeBSD.org/gnome From rnoland at FreeBSD.org Tue Apr 7 12:27:16 2009 From: rnoland at FreeBSD.org (Robert Noland) Date: Tue Apr 7 12:27:23 2009 Subject: mplayer fails to build on current In-Reply-To: <104bdc11c08b1998f47241828d685db2.squirrel@cygnus.homeunix.com> References: <104bdc11c08b1998f47241828d685db2.squirrel@cygnus.homeunix.com> Message-ID: <1239132380.1947.22.camel@balrog.2hip.net> On Tue, 2009-04-07 at 10:23 -0300, Nenhum_de_Nos wrote: > hi, > > anyone else having problems too ? > > I've updated portsnap several times. I get this: > > gmake[1]: Entering directory > `/usr/ports/multimedia/mplayer/work/MPlayer-1.0rc2/libavcodec' > cc -O2 -pipe -O3 -ffast-math -fomit-frame-pointer -fno-strict-aliasing > -I./libavcodec -I./libavformat -Wdisabled-optimization -Wno-pointer-sign > -Wdeclaration-after-statement -I. -I. -I./libavutil -O2 -pipe -O3 > -ffast-math -fomit-frame-pointer -fno-strict-aliasing -D_LARGEFILE_SOURCE > -D_FILE_OFFSET_BITS=64 -D_LARGEFILE64_SOURCE -DHAVE_CONFIG_H > -I/usr/local/include/freetype2 -I.. -I../libavutil -I/usr/local/include > -I/usr/local/include -I/usr/local/include/freetype2 -I/usr/local/include > -D_THREAD_SAFE -I/usr/local/include/gtk-2.0 > -I/usr/local/lib/gtk-2.0/include -I/usr/local/include/atk-1.0 > -I/usr/local/include/cairo -I/usr/local/include/pango-1.0 > -I/usr/local/include -I/usr/local/include/glib-2.0 > -I/usr/local/lib/glib-2.0/include -I/usr/local/include/pixman-1 > -I/usr/local/include/freetype2 -I../libswscale -I../libavcodec > -DBROKEN_RELOCATIONS -DHAVE_AV_CONFIG_H -D_FILE_OFFSET_BITS=64 > -D_LARGEFILE_SOURCE -D_ISOC9X_SOURCE -I.. -I.. -I../libavutil > -Wdisabled-optimization -Wno-pointer-sign -Wdeclaration-after-statement > -I. -I.. -I../libavutil -O2 -pipe -O3 -ffast-math -fomit-frame-pointer > -fno-strict-aliasing -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 > -D_LARGEFILE64_SOURCE -DHAVE_CONFIG_H -I/usr/local/include/freetype2 -I... > -I.../libavutil -I/usr/local/include -I/usr/local/include > -I/usr/local/include/freetype2 -I/usr/local/include -D_THREAD_SAFE > -I/usr/local/include/gtk-2.0 -I/usr/local/lib/gtk-2.0/include > -I/usr/local/include/atk-1.0 -I/usr/local/include/cairo > -I/usr/local/include/pango-1.0 -I/usr/local/include > -I/usr/local/include/glib-2.0 -I/usr/local/lib/glib-2.0/include > -I/usr/local/include/pixman-1 -I/usr/local/include/freetype2 -c -o > dsputil.o dsputil.c > mpegvideo.h:777: error: nested function 'ff_get_mb_score' declared but > never defined > mpegvideo.h:775: error: nested function 'ff_epzs_motion_search' declared > but never defined > gmake[1]: *** [dsputil.o] Error 1 > gmake[1]: Leaving directory > `/usr/ports/multimedia/mplayer/work/MPlayer-1.0rc2/libavcodec' > gmake: *** [libavcodec/libavcodec.a] Error 2 > *** Error code 1 > > Stop in /usr/ports/multimedia/mplayer. > *** Error code 1 > > FreeBSD xxx 8.0-CURRENT FreeBSD 8.0-CURRENT #2: Mon Mar 23 16:51:53 BRT > 2009 xxx:/usr/obj/usr/src/sys/Core2Duo8 amd64 You need to update your -CURRENT, this has been fixed recently. robert. > thanks, > > matheus -- Robert Noland FreeBSD -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 196 bytes Desc: This is a digitally signed message part Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20090407/63c2b356/attachment.pgp From mav at FreeBSD.org Tue Apr 7 12:51:20 2009 From: mav at FreeBSD.org (Alexander Motin) Date: Tue Apr 7 12:51:26 2009 Subject: AMD 780G chipset major issues 1/3 (ata, ataati) In-Reply-To: <1239063789.00097213.1239052203@10.7.7.3> References: <1239063789.00097213.1239052203@10.7.7.3> Message-ID: <49DBAEB5.7010500@FreeBSD.org> Diego Depaoli wrote: > Hi all, > please compare these logs > > 1 -> without ataati > #dmesg |grep ata > atapci0: port > 0xc000-0xc007,0xb000-0xb003,0xa000-0xa007,0x9000-0x9003,0x8000-0x800f > mem 0xfe8ffc00-0xfe8fffff irq 22 at device 17.0 on pci0 > atapci0: [ITHREAD] > ata2: on atapci0 > ata2: [ITHREAD] > ata3: on atapci0 > ata3: [ITHREAD] > atapci1: port > 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xff00-0xff0f at device 20.1 on > pci0 > ata0: on atapci1 > ata0: [ITHREAD] > ata1: on atapci1 > ata1: [ITHREAD] > acd0: DVDR at ata1-master UDMA33 > ad4: 305245MB at ata2-master UDMA33 > ad6: 305245MB at ata3-master UDMA33 > > my sata disks are udma33 > > 2 -> with ataati loaded as module > atapci0: port > 0xc000-0xc007,0xb000-0xb003,0xa000-0xa007,0x9000-0x9003,0x8000-0x800f > mem 0xfe8ffc00-0xfe8fffff irq 22 at device 17.0 on pci0 > atapci0: [ITHREAD] > atapci0: AHCI Version 01.10 controller with 4 ports PM supported > ata2: on atapci0 > ata2: port is not ready (timeout 0ms) tfd = 000001d0 > ata2: software reset clear timeout > ata2: [ITHREAD] > ata3: on atapci0 > ata3: port is not ready (timeout 0ms) tfd = 000001d0 > ata3: software reset clear timeout > ata3: [ITHREAD] > ata4: on atapci0 > ata4: [ITHREAD] > ata5: on atapci0 > ata5: [ITHREAD] > atapci1: port > 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xff00-0xff0f at device 20.1 on > pci0 > ata0: on atapci1 > ata0: [ITHREAD] > ad4: 305245MB at ata2-master SATA300 > ad6: 305245MB at ata3-master SATA300 > > my sata disks are right, but ata1 and acd0 vanished Is your DVD drive SATA or PATA? Can you boot with verbose messages enabled? How much different ATA channels do you really have on your mobo? -- Alexander Motin From lists at c0mplx.org Tue Apr 7 13:02:57 2009 From: lists at c0mplx.org (Kurt Jaeger) Date: Tue Apr 7 13:03:04 2009 Subject: AMD 780G chipset major issues 1/3 (ata, ataati) In-Reply-To: <49DBAEB5.7010500@FreeBSD.org> References: <1239063789.00097213.1239052203@10.7.7.3> <49DBAEB5.7010500@FreeBSD.org> Message-ID: <20090407200257.GB19850@home.opsec.eu> > > 2 -> with ataati loaded as module [...] > > ad4: 305245MB at ata2-master SATA300 > > ad6: 305245MB at ata3-master SATA300 > > > > my sata disks are right, but ata1 and acd0 vanished > > Is your DVD drive SATA or PATA? Can you boot with verbose messages > enabled? How much different ATA channels do you really have on your mobo? Similar problem with a recent 7.1 or 7.2. I have a SATA DVD. Verbose boot see http://opsec.eu/backup/dmesg.boot-long I have 5 channels (where ata1 is missing!): ATA channel 0: Master: no device present Slave: no device present ATA channel 2: Master: ad4 SATA revision 2.x Slave: no device present ATA channel 3: Master: no device present Slave: no device present ATA channel 4: Master: no device present Slave: no device present ATA channel 5: Master: no device present Slave: no device present -- pi@opsec.eu +49 171 3101372 11 years to go ! From tinderbox at freebsd.org Tue Apr 7 13:06:06 2009 From: tinderbox at freebsd.org (FreeBSD Tinderbox) Date: Tue Apr 7 13:06:24 2009 Subject: [head tinderbox] failure on ia64/ia64 Message-ID: <20090407200602.75DA37302F@freebsd-current.sentex.ca> TB --- 2009-04-07 18:16:46 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2009-04-07 18:16:46 - starting HEAD tinderbox run for ia64/ia64 TB --- 2009-04-07 18:16:46 - cleaning the object tree TB --- 2009-04-07 18:17:06 - cvsupping the source tree TB --- 2009-04-07 18:17:06 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/ia64/ia64/supfile TB --- 2009-04-07 18:17:18 - building world TB --- 2009-04-07 18:17:18 - MAKEOBJDIRPREFIX=/obj TB --- 2009-04-07 18:17:18 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-04-07 18:17:18 - TARGET=ia64 TB --- 2009-04-07 18:17:18 - TARGET_ARCH=ia64 TB --- 2009-04-07 18:17:18 - TZ=UTC TB --- 2009-04-07 18:17:18 - __MAKE_CONF=/dev/null TB --- 2009-04-07 18:17:18 - cd /src TB --- 2009-04-07 18:17:18 - /usr/bin/make -B buildworld >>> World build started on Tue Apr 7 18:17:19 UTC 2009 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything [...] ===> usr.sbin/tzsetup (all) cc -O2 -pipe -I/src/usr.sbin/tzsetup -std=gnu99 -c /src/usr.sbin/tzsetup/tzsetup.c cc -O2 -pipe -I/src/usr.sbin/tzsetup -std=gnu99 -o tzsetup tzsetup.o -ldialog -lncurses gzip -cn /src/usr.sbin/tzsetup/tzsetup.8 > tzsetup.8.gz ===> usr.sbin/uathload (all) cc -O2 -pipe -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wunused-parameter -Wno-uninitialized -Wno-pointer-sign -c /src/usr.sbin/uathload/uathload.c ld -b binary -d -warn-common -r -d -o ar5523.o ar5523.bin ld: failed to merge target specific data of file ar5523.bin *** Error code 1 Stop in /src/usr.sbin/uathload. *** Error code 1 Stop in /src/usr.sbin. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-04-07 20:06:02 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-04-07 20:06:02 - ERROR: failed to build world TB --- 2009-04-07 20:06:02 - 5316.77 user 393.38 system 6556.12 real http://tinderbox.des.no/tinderbox-head-HEAD-ia64-ia64.full From mav at FreeBSD.org Tue Apr 7 13:12:51 2009 From: mav at FreeBSD.org (Alexander Motin) Date: Tue Apr 7 13:12:58 2009 Subject: AMD 780G chipset major issues 1/3 (ata, ataati) In-Reply-To: <20090407200257.GB19850@home.opsec.eu> References: <1239063789.00097213.1239052203@10.7.7.3> <49DBAEB5.7010500@FreeBSD.org> <20090407200257.GB19850@home.opsec.eu> Message-ID: <49DBB3C0.9010800@FreeBSD.org> Kurt Jaeger wrote: >>> 2 -> with ataati loaded as module > [...] >>> ad4: 305245MB at ata2-master SATA300 >>> ad6: 305245MB at ata3-master SATA300 >>> >>> my sata disks are right, but ata1 and acd0 vanished >> Is your DVD drive SATA or PATA? Can you boot with verbose messages >> enabled? How much different ATA channels do you really have on your mobo? > > Similar problem with a recent 7.1 or 7.2. AHCI driver was significantly modified on CURRENT, so STABLE results are not so informative. -- Alexander Motin From ndenev at gmail.com Tue Apr 7 13:15:50 2009 From: ndenev at gmail.com (Niki Denev) Date: Tue Apr 7 13:15:56 2009 Subject: axe(4) (Belkin F5D5055) problems In-Reply-To: References: <75656435-49E2-457A-9CFE-8706CD44916E@gmail.com> <20090328080924.GD99923@michelle.cdnetworks.co.kr> <2e77fc10903280259s5a761cacs398b88649a2367fe@mail.gmail.com> <20090328102735.GE99923@michelle.cdnetworks.co.kr> <2e77fc10903280942u7c934aa4w80176680e9dff6d7@mail.gmail.com> <2e77fc10903281539h7b713711w116a90fd2bfadbcf@mail.gmail.com> <20090330021648.GE7076@michelle.cdnetworks.co.kr> <20090330024748.GF7076@michelle.cdnetworks.co.kr> Message-ID: <2e77fc10904071315q66d725bl76229d9bffd92f35@mail.gmail.com> On Mon, Mar 30, 2009 at 12:34 PM, Sepherosa Ziehau wrote: > On Mon, Mar 30, 2009 at 10:47 AM, Pyun YongHyeon wrote: >> On Mon, Mar 30, 2009 at 11:16:48AM +0900, Pyun YongHyeon wrote: >>> On Sun, Mar 29, 2009 at 12:39:22AM +0200, Niki Denev wrote: >>> > On Sat, Mar 28, 2009 at 6:42 PM, Niki Denev wrote: >>> > > On Sat, Mar 28, 2009 at 12:27 PM, Pyun YongHyeon wrote: >>> > >> On Sat, Mar 28, 2009 at 11:59:13AM +0200, Niki Denev wrote: >>> > >>> 2009/3/28 Pyun YongHyeon : >>> > >>> > On Fri, Mar 27, 2009 at 09:14:06PM +0200, Nikolay Denev wrote: >>> > >>> >> -----BEGIN PGP SIGNED MESSAGE----- >>> > >>> >> Hash: SHA1 >>> > >>> >> >>> > >>> >> Hello, >>> > >>> >> >>> > >>> >> I'm running -current from 23.03.09 and I'm experiencing some axe(4) >>> > >>> >> problems. >>> > >>> >> Basically the network connection works but when some more serious >>> > >>> >> traffic hits the >>> > >>> >> interface (i.e. torrent download) it then dies, ifconfig down/up >>> > >>> >> does not help, only replugging of the adapter. >>> > >>> >> >>> > >>> >> I've tried running with hw.usb2.axe.debug=15 and the output was many >>> > >>> >> lines of: >>> > >>> >> >>> > >>> >> ? ?axe_bulk_write_callback:853: transfer complete >>> > >>> >> >>> > >>> >> then a pause of several seconds and the kernel begins to print : >>> > >>> >> >>> > >>> >> ? ?axe_bulk_write_callback:925: transfer error, USB_ERR_TIMEOUT >>> > >>> >> >>> > >>> >> Another strange thing that I noticed is that, while the interface >>> > >>> >> seems to be >>> > >>> >> connected and working, if I type many times ifconfig ue0 consecutively >>> > >>> >> most of the time it would show different settings for the auto >>> > >>> >> negotiated link. >>> > >>> >> I.e. it would cycle between 100baseTX-FDX, 1000baseT-FDX, no carrier, >>> > >>> >> 100BaseT-FDX hw-loopback and 1000BaseT-FDX hw-loopback. >>> > >>> >> >>> > >>> >> The switch does not seem to register link flaps. >>> > >>> >> >>> > >>> > >>> > >>> > axe(4) requires exact link state/speed information from mii(4) to >>> > >>> > reprogram controller to resolved speed/duplex. In this case >>> > >>> > ukphy(4) seems to report fake link state/speed to axe(4). >>> > >>> > >>> > >>> >> The kernel messages for the interface are : >>> > >>> >> >>> > >>> >> ? ?ugen2.5: at usbus2 >>> > >>> >> ? ?axe0: on usbus2 >>> > >>> >> ? ?axe0: PHYADDR 0xe0:0x01 >>> > >>> >> ? ?miibus0: on axe0 >>> > >>> >> ? ?ukphy0: PHY 1 on miibus0 >>> > >>> >> ? ?ukphy0: ?10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, >>> > >>> >> 1000baseT, 1000baseT-FDX, auto >>> > >>> >> ? ?ue0: on axe0 >>> > >>> >> ? ?ue0: Ethernet address: 00:11:50:xx:xx:xx >>> > >>> >> >>> > >>> >> devinfo -vr | grep phy >>> > >>> >> ukphy0 pnpinfo oui=0xa0bc model=0x1 rev=0x2 at phyno=1 >>> > >>> >> >>> > >>> > >>> > >>> > This looks like Agere systems ET110C TruePHY. Would you try >>> > >>> > attached patch? Because truephy(4) pokes some undocumented PHY >>> > >>> > registers on PHY reset I'm not sure this model also requires that >>> > >>> > magic to make it work though. >>> > >>> > >>> > >>> >>> > >>> Hi Pyun, >>> > >>> >>> > >>> Thanks for the patch. >>> > >>> >>> > >>> With it the PHY is now detected as truephy. >>> > >>> The only thing that i notice is that if the media status changes displayed with >>> > >>> ifconfig are less frequent, and I mostly see 1000baseT-FDX and 100baseT-HDX >>> > >>> The packet loss is still there, and the interface again stops to work >>> > >>> after some time. >>> > >>> >>> > >> >>> > >> Ok, revert previous patch and try attached one. This one does not >>> > >> try to load ET1011C dsp codes. If this does not work next thing >>> > >> would be try to load dsp code for ET1011C revision 1 model. >>> > >> Not sure where I can find required dsp code. >>> > >> >>> > > >>> > > There don't seem to be any improvement with the new patch. >>> > > The packetloss and media status changes are still here. >>> > > Maybe check Linux/Solaris/OtherBSD driver? >>> > > >>> > > -- >>> > > Niki >>> > > >>> > >>> > LSI seem to have several documents about this phy chip, including >>> > datasheet (which you probably have) and errata : >>> > http://www.lsi.com/DistributionSystem/AssetDocument/documentation/networking/ethernet/et1011c/DS06-161GPHY_ET1011C_09-28-2007.pdf >>> > http://www.lsi.com/DistributionSystem/AssetDocument/documentation/networking/ethernet/et1011c/ET1011C_Errata_08June2007.pdf >>> > >>> >>> Yes, but unfortunately it is for model 3 or model 4. Yours is model >>> 1. In fact I have no idea whether model 1 is ET1011C. It seems that >> >> I was wrong. The datasheet is for model 1, but revision number is >> 4. >> >>> there are ET1011A or ET1011B PHYs. >>> >>> Sepherosa, do you have more information on ET1011A/ET1011B PHY? > > Nope, LSI site only has et1011c data sheet. ?However, the model in the > data sheet mismatches the PHY model on my available hardware. > >> It looks odd to me, by chance is model 4 typo? Does et(4) really > > Nah, its not typo, at least the hardwares I have (one OEM and one EVB) > uses model 4. > >> recognize the PHY as truephy(4)? Also CCed to Xin Li who ported the >> et(4) to FreeBSD. > > > > -- > Live Free or Die > I have temporarily replaced the belkin USB ethernet interface with an Apple USB ethernet, which also uses the axe(4) driver, but is only 100Mbit/s. As I suspected the negotiation problems do not exist with it, and everything seemed ok, until it started to stop working exactly like the previous adapter. Pings start to return "buffer space not available" and replugging or "usbconfig reset" the interface returns it to normal status. It looks like that the packet loss that I've experienced with the Belkin gigabit adabter is one problem, and the interface stopping to work another. P.S.: I don't know if it could be my USB hardware, because the machine is a little bit "exotic", an HP ex470 MediaSmartServer, which was supposedly designed to run only embedded version of Windows and has a nasty SiS chipset in it (with the unsupported sis191 gigabit adapter) From trebestie at gmail.com Tue Apr 7 13:37:33 2009 From: trebestie at gmail.com (Diego Depaoli) Date: Tue Apr 7 13:37:41 2009 Subject: AMD 780G chipset major issues 3/3 (btx) In-Reply-To: <1239132158.1947.21.camel@balrog.2hip.net> References: <83e5fb980904061402q73940f8at4ec4b8f821354320@mail.gmail.com> <200904062321.47691.thierry.herbelot@free.fr> <20090407095804.G8569@rust.salford.ac.uk> <1239132158.1947.21.camel@balrog.2hip.net> Message-ID: <83e5fb980904071337r4dfae6c0re1be948361c229e2@mail.gmail.com> On Tue, Apr 7, 2009 at 9:22 PM, Robert Noland wrote: >> On Tue, 2009-04-07 at 09:59 +0100, Mark Powell wrote: >> Could we have some make/models guys? I have an Asrock A780GM-LE >> I'm interested in a new integrated >> graphics MB for CURRENT and want to know what to avoid. I had a socket 7 board where FreeBSD worked well 'out of the box', but, I'm sorry, I don't remember the model :-) > > I can't really speak for the other components, but afaik, all of the > radeon IGPs should be working ok. You're right, I got no problem with drm and radeon. Regards -- Diego Depaoli From jkim at FreeBSD.org Tue Apr 7 13:52:46 2009 From: jkim at FreeBSD.org (Jung-uk Kim) Date: Tue Apr 7 13:52:53 2009 Subject: xorg loops In-Reply-To: <1238979841.1829.20.camel@balrog.2hip.net> References: <49D8D03B.8090302@arcor.de> <1238979841.1829.20.camel@balrog.2hip.net> Message-ID: <200904071652.29530.jkim@FreeBSD.org> On Sunday 05 April 2009 09:04 pm, Robert Noland wrote: > On Sun, 2009-04-05 at 19:53 -0500, Sean C. Farley wrote: > > While the mouse driver is patched, I do not see where > > XPS2_SUPPORT is actually set anywhere in the build. > > I remember messing with that after the last upgrade, when I was > trying to deal with mice issues. jkim@ said something about it > only being supported on more recent platforms. http://lists.freebsd.org/pipermail/cvs-src/2008-April/089763.html http://lists.freebsd.org/pipermail/cvs-src/2008-April/090051.html http://lists.freebsd.org/pipermail/cvs-src/2008-April/090052.html http://lists.freebsd.org/pipermail/cvs-ports/2008-April/146815.html > > Defining it allows the driver to detect my mouse. Actually, > > before the patch it would not even let me set it to > > GlidePointPS/2. It seems the xserver patch is in the attic now: http://www.freebsd.org/cgi/cvsweb.cgi/ports/x11-servers/xorg-server/files/Attic/patch-Xserver-hw-xfree86-os-support-xf86_OSlib.h I think you should restore the patch, rebuild, and reinstall xserver and xf86-input-mouse to enable it. Alternatively, it can be moved to configure script of xf86-input-mouse, I think. I don't know which is prefered by X.org developers theses days. :-( Jung-uk Kim From rnoland at FreeBSD.org Tue Apr 7 13:59:26 2009 From: rnoland at FreeBSD.org (Robert Noland) Date: Tue Apr 7 13:59:33 2009 Subject: xorg loops In-Reply-To: <200904071652.29530.jkim@FreeBSD.org> References: <49D8D03B.8090302@arcor.de> <1238979841.1829.20.camel@balrog.2hip.net> <200904071652.29530.jkim@FreeBSD.org> Message-ID: <1239137910.1947.23.camel@balrog.2hip.net> On Tue, 2009-04-07 at 16:52 -0400, Jung-uk Kim wrote: > On Sunday 05 April 2009 09:04 pm, Robert Noland wrote: > > On Sun, 2009-04-05 at 19:53 -0500, Sean C. Farley wrote: > > > While the mouse driver is patched, I do not see where > > > XPS2_SUPPORT is actually set anywhere in the build. > > > > I remember messing with that after the last upgrade, when I was > > trying to deal with mice issues. jkim@ said something about it > > only being supported on more recent platforms. > > http://lists.freebsd.org/pipermail/cvs-src/2008-April/089763.html > http://lists.freebsd.org/pipermail/cvs-src/2008-April/090051.html > http://lists.freebsd.org/pipermail/cvs-src/2008-April/090052.html > http://lists.freebsd.org/pipermail/cvs-ports/2008-April/146815.html > > > > Defining it allows the driver to detect my mouse. Actually, > > > before the patch it would not even let me set it to > > > GlidePointPS/2. > > It seems the xserver patch is in the attic now: > > http://www.freebsd.org/cgi/cvsweb.cgi/ports/x11-servers/xorg-server/files/Attic/patch-Xserver-hw-xfree86-os-support-xf86_OSlib.h > > I think you should restore the patch, rebuild, and reinstall xserver > and xf86-input-mouse to enable it. Alternatively, it can be moved to > configure script of xf86-input-mouse, I think. I don't know which is > prefered by X.org developers theses days. :-( Hrm, all of the os-support stuff is moved to the mouse driver now... robert. > Jung-uk Kim > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" -- Robert Noland FreeBSD -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 196 bytes Desc: This is a digitally signed message part Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20090407/26f1d5f2/attachment.pgp From trebestie at gmail.com Tue Apr 7 14:02:31 2009 From: trebestie at gmail.com (Diego Depaoli) Date: Tue Apr 7 14:02:37 2009 Subject: AMD 780G chipset major issues 1/3 (ata, ataati) In-Reply-To: <49DBB3C0.9010800@FreeBSD.org> References: <1239063789.00097213.1239052203@10.7.7.3> <49DBAEB5.7010500@FreeBSD.org> <20090407200257.GB19850@home.opsec.eu> <49DBB3C0.9010800@FreeBSD.org> Message-ID: <83e5fb980904071402k600cbc09hcde8994cb5465f52@mail.gmail.com> On Tue, Apr 7, 2009 at 10:12 PM, Alexander Motin wrote: > Kurt Jaeger wrote: >>>> >>>> 2 -> with ataati loaded as module >> >> [...] >>>> >>>> ad4: 305245MB at ata2-master SATA300 >>>> ad6: 305245MB at ata3-master SATA300 >>>> >>>> my sata disks are right, but ata1 and acd0 vanished >>> >>> Is your DVD drive SATA or PATA? It's PATA >>Can you boot with verbose messages >>> enabled? yes, it's here http://pastebin.com/m6fae60ce Regards -- Diego Depaoli From jkim at FreeBSD.org Tue Apr 7 14:20:01 2009 From: jkim at FreeBSD.org (Jung-uk Kim) Date: Tue Apr 7 14:20:08 2009 Subject: xorg loops In-Reply-To: <1239137910.1947.23.camel@balrog.2hip.net> References: <49D8D03B.8090302@arcor.de> <200904071652.29530.jkim@FreeBSD.org> <1239137910.1947.23.camel@balrog.2hip.net> Message-ID: <200904071719.43150.jkim@FreeBSD.org> On Tuesday 07 April 2009 04:58 pm, Robert Noland wrote: > On Tue, 2009-04-07 at 16:52 -0400, Jung-uk Kim wrote: > > On Sunday 05 April 2009 09:04 pm, Robert Noland wrote: > > > On Sun, 2009-04-05 at 19:53 -0500, Sean C. Farley wrote: > > > > While the mouse driver is patched, I do not see where > > > > XPS2_SUPPORT is actually set anywhere in the build. > > > > > > I remember messing with that after the last upgrade, when I was > > > trying to deal with mice issues. jkim@ said something about it > > > only being supported on more recent platforms. > > > > http://lists.freebsd.org/pipermail/cvs-src/2008-April/089763.html > > http://lists.freebsd.org/pipermail/cvs-src/2008-April/090051.html > > http://lists.freebsd.org/pipermail/cvs-src/2008-April/090052.html > > http://lists.freebsd.org/pipermail/cvs-ports/2008-April/146815.ht > >ml > > > > > > Defining it allows the driver to detect my mouse. Actually, > > > > before the patch it would not even let me set it to > > > > GlidePointPS/2. > > > > It seems the xserver patch is in the attic now: > > > > http://www.freebsd.org/cgi/cvsweb.cgi/ports/x11-servers/xorg-serv > >er/files/Attic/patch-Xserver-hw-xfree86-os-support-xf86_OSlib.h > > > > I think you should restore the patch, rebuild, and reinstall > > xserver and xf86-input-mouse to enable it. Alternatively, it can > > be moved to configure script of xf86-input-mouse, I think. I > > don't know which is prefered by X.org developers theses days. :-( > > Hrm, all of the os-support stuff is moved to the mouse driver > now... Okay, try the attached patch, then. Jung-uk Kim -------------- next part -------------- --- x11-drivers/xf86-input-mouse/Makefile.orig 2009-04-07 16:34:36.000000000 -0400 +++ x11-drivers/xf86-input-mouse/Makefile 2009-04-07 17:15:48.000000000 -0400 @@ -7,7 +7,7 @@ PORTNAME= xf86-input-mouse PORTVERSION= 1.4.0 -PORTREVISION= 4 +PORTREVISION= 5 CATEGORIES= x11-drivers MAINTAINER= x11@FreeBSD.org --- x11-drivers/xf86-input-mouse/files/patch-src-bsd_mouse.c.orig 2009-02-04 13:31:00.000000000 -0500 +++ x11-drivers/xf86-input-mouse/files/patch-src-bsd_mouse.c 2009-04-07 17:11:06.000000000 -0400 @@ -1,11 +1,18 @@ --- src/bsd_mouse.c.orig 2008-11-26 23:11:36.000000000 -0500 -+++ src/bsd_mouse.c 2009-02-04 12:56:32.000000000 -0500 ++++ src/bsd_mouse.c 2009-04-07 17:10:17.000000000 -0400 @@ -1,4 +1,3 @@ - /* * Copyright (c) 1999-2003 by The XFree86 Project, Inc. * -@@ -75,11 +74,13 @@ +@@ -71,15 +70,20 @@ + static const char *FindDevice(InputInfoPtr, const char *, int); + + #if defined(__FreeBSD__) || defined(__FreeBSD_kernel__) || defined(__DragonFly__) ++#if !defined(XPS2_SUPPORT) && (__FreeBSD_kernel_version >= 700106) ++#define XPS2_SUPPORT ++#endif + /* These are for FreeBSD and DragonFly */ #define DEFAULT_MOUSE_DEV "/dev/mouse" #define DEFAULT_SYSMOUSE_DEV "/dev/sysmouse" #define DEFAULT_PS2_DEV "/dev/psm0" @@ -19,7 +26,7 @@ NULL }; #elif (defined(__OpenBSD__) || defined(__NetBSD__)) && defined(WSCONS_SUPPORT) -@@ -100,7 +101,11 @@ +@@ -100,7 +104,11 @@ #if defined(__NetBSD__) return MSE_SERIAL | MSE_BUS | MSE_PS2 | MSE_AUTO; #elif defined(__FreeBSD__) || defined(__FreeBSD_kernel__) || defined(__DragonFly__) @@ -32,7 +39,7 @@ #else return MSE_SERIAL | MSE_BUS | MSE_PS2 | MSE_XPS2 | MSE_AUTO; #endif -@@ -179,10 +184,31 @@ +@@ -179,10 +187,31 @@ { MOUSE_PROTO_THINK, "ThinkingMouse" }, { MOUSE_PROTO_SYSMOUSE, "SysMouse" } }; @@ -65,7 +72,7 @@ int i; mousehw_t hw; mousemode_t mode; -@@ -190,10 +216,16 @@ +@@ -190,10 +219,16 @@ if (pInfo->fd == -1) return NULL; @@ -83,7 +90,7 @@ /* interrogate the driver and get some intelligence on the device. */ hw.iftype = MOUSE_IF_UNKNOWN; hw.model = MOUSE_MODEL_GENERIC; -@@ -209,9 +241,18 @@ +@@ -209,9 +244,18 @@ protoPara[0] = mode.syncmask[0]; protoPara[1] = mode.syncmask[1]; } @@ -104,7 +111,7 @@ } } } -@@ -234,41 +275,41 @@ +@@ -234,41 +278,41 @@ (protocol && xf86NameCmp(protocol, "SysMouse") == 0)) { /* * As the FreeBSD sysmouse driver defaults to protocol level 0 @@ -163,7 +170,7 @@ } return FALSE; } -@@ -276,17 +317,17 @@ +@@ -276,17 +320,17 @@ static const char * FindDevice(InputInfoPtr pInfo, const char *protocol, int flags) { @@ -185,7 +192,7 @@ #endif } else { /* -@@ -295,28 +336,32 @@ +@@ -295,28 +339,32 @@ * the test for whether /dev/sysmouse is usable can be made. */ if (!strcmp(*pdev, DEFAULT_MOUSE_DEV)) { @@ -231,7 +238,7 @@ break; } } -@@ -782,7 +827,9 @@ +@@ -782,7 +830,9 @@ p->CheckProtocol = CheckProtocol; #if (defined(__FreeBSD__) || defined(__FreeBSD_kernel__) || defined(__DragonFly__)) && defined(MOUSE_PROTO_SYSMOUSE) p->SetupAuto = SetupAuto; From jkim at FreeBSD.org Tue Apr 7 14:57:21 2009 From: jkim at FreeBSD.org (Jung-uk Kim) Date: Tue Apr 7 14:57:29 2009 Subject: AMD 780G chipset major issues 1/3 (ata, ataati) In-Reply-To: <83e5fb980904071402k600cbc09hcde8994cb5465f52@mail.gmail.com> References: <1239063789.00097213.1239052203@10.7.7.3> <49DBB3C0.9010800@FreeBSD.org> <83e5fb980904071402k600cbc09hcde8994cb5465f52@mail.gmail.com> Message-ID: <200904071757.04734.jkim@FreeBSD.org> On Tuesday 07 April 2009 05:02 pm, Diego Depaoli wrote: > On Tue, Apr 7, 2009 at 10:12 PM, Alexander Motin wrote: > > Kurt Jaeger wrote: > >>>> 2 -> with ataati loaded as module > >> > >> [...] > >> > >>>> ad4: 305245MB at ata2-master > >>>> SATA300 ad6: 305245MB at > >>>> ata3-master SATA300 > >>>> > >>>> my sata disks are right, but ata1 and acd0 vanished > >>> > >>> Is your DVD drive SATA or PATA? > > It's PATA > > >>Can you boot with verbose messages > >> > >>> enabled? > > yes, it's here > http://pastebin.com/m6fae60ce I have a similar board and it seems to share the broken ACPI DSDT. See the following Linux PR for example: https://bugzilla.novell.com/show_bug.cgi?id=345124 Basically, big chunks of DSDT are being ignored because it does not comply with ACPI specification 2.0+ but it is okay with M$ OSes, aka "executable code at module level" bug: http://www.acpica.org/bugzilla/show_bug.cgi?id=762 I believe the DSDT was almost unmodified from original BIOS for AMD CAT2 reference platform. Actually, I have given up on fixing it myself because I couldn't find enough information about the board and chipset. :-( Jung-uk Kim From mav at mavhome.dp.ua Tue Apr 7 13:58:03 2009 From: mav at mavhome.dp.ua (Alexander Motin) Date: Tue Apr 7 15:00:52 2009 Subject: AMD 780G chipset major issues 2/3 (snd_hda) In-Reply-To: <1239063792.00097228.1239052802@10.7.7.3> References: <1239063789.00097214.1239052203@10.7.7.3> <1239063790.00097218.1239052203@10.7.7.3> <1239063792.00097228.1239052802@10.7.7.3> Message-ID: <49DBBE59.2080801@mavhome.dp.ua> Diego Depaoli wrote: > On Mon, Apr 6, 2009 at 11:06 PM, Paul B. Mahol wrote: >> Because pcm0 switched position with pcm1 :-) > Already noticed. > Do you know why? It is really interesting question, but probably to the PCI guys. -- Alexander Motin From rnoland at FreeBSD.org Tue Apr 7 15:15:59 2009 From: rnoland at FreeBSD.org (Robert Noland) Date: Tue Apr 7 15:16:06 2009 Subject: AMD 780G chipset major issues 2/3 (snd_hda) In-Reply-To: <49DBBE59.2080801@mavhome.dp.ua> References: <1239063789.00097214.1239052203@10.7.7.3> <1239063790.00097218.1239052203@10.7.7.3> <1239063792.00097228.1239052802@10.7.7.3> <49DBBE59.2080801@mavhome.dp.ua> Message-ID: <1239142508.1947.26.camel@balrog.2hip.net> On Tue, 2009-04-07 at 23:58 +0300, Alexander Motin wrote: > Diego Depaoli wrote: > > On Mon, Apr 6, 2009 at 11:06 PM, Paul B. Mahol wrote: > >> Because pcm0 switched position with pcm1 :-) > > Already noticed. > > Do you know why? > > It is really interesting question, but probably to the PCI guys. I think it is due to bus enumeration... the first one found (i.e. lower bus id) becomes pcm0. If I plug in the radeon HD 3850 which has hdmi audio, it ends up being pcm0, instead of my rear ports. I also have a seperate codec for front ports, which is a bit of a pain, but... robert. -- Robert Noland FreeBSD -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 196 bytes Desc: This is a digitally signed message part Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20090407/8310de7f/attachment.pgp From scf at FreeBSD.org Tue Apr 7 15:53:25 2009 From: scf at FreeBSD.org (Sean C. Farley) Date: Tue Apr 7 15:53:32 2009 Subject: xorg loops In-Reply-To: <200904071719.43150.jkim@FreeBSD.org> References: <49D8D03B.8090302@arcor.de> <200904071652.29530.jkim@FreeBSD.org> <1239137910.1947.23.camel@balrog.2hip.net> <200904071719.43150.jkim@FreeBSD.org> Message-ID: On Tue, 7 Apr 2009, Jung-uk Kim wrote: > On Tuesday 07 April 2009 04:58 pm, Robert Noland wrote: >> On Tue, 2009-04-07 at 16:52 -0400, Jung-uk Kim wrote: >>> On Sunday 05 April 2009 09:04 pm, Robert Noland wrote: >>>> On Sun, 2009-04-05 at 19:53 -0500, Sean C. Farley wrote: >>>>> While the mouse driver is patched, I do not see where >>>>> XPS2_SUPPORT is actually set anywhere in the build. >>>> >>>> I remember messing with that after the last upgrade, when I was >>>> trying to deal with mice issues. jkim@ said something about it >>>> only being supported on more recent platforms. >>> >>> http://lists.freebsd.org/pipermail/cvs-src/2008-April/089763.html >>> http://lists.freebsd.org/pipermail/cvs-src/2008-April/090051.html >>> http://lists.freebsd.org/pipermail/cvs-src/2008-April/090052.html >>> http://lists.freebsd.org/pipermail/cvs-ports/2008-April/146815.html >>> >>>>> Defining it allows the driver to detect my mouse. Actually, >>>>> before the patch it would not even let me set it to >>>>> GlidePointPS/2. >>> >>> It seems the xserver patch is in the attic now: >>> >>> http://www.freebsd.org/cgi/cvsweb.cgi/ports/x11-servers/xorg-serv >>> er/files/Attic/patch-Xserver-hw-xfree86-os-support-xf86_OSlib.h >>> >>> I think you should restore the patch, rebuild, and reinstall >>> xserver and xf86-input-mouse to enable it. Alternatively, it can >>> be moved to configure script of xf86-input-mouse, I think. I >>> don't know which is prefered by X.org developers theses days. :-( >> >> Hrm, all of the os-support stuff is moved to the mouse driver >> now... > > Okay, try the attached patch, then. That works for me. Thank you. Sean -- scf@FreeBSD.org From matheus at eternamente.info Tue Apr 7 15:54:27 2009 From: matheus at eternamente.info (Nenhum_de_Nos) Date: Tue Apr 7 15:54:38 2009 Subject: mplayer fails to build on current In-Reply-To: <1239132380.1947.22.camel@balrog.2hip.net> References: <104bdc11c08b1998f47241828d685db2.squirrel@cygnus.homeunix.com> <1239132380.1947.22.camel@balrog.2hip.net> Message-ID: <30403eeb3e377555967882ea8e0031fe.squirrel@cygnus.homeunix.com> On Tue, April 7, 2009 16:26, Robert Noland wrote: > You need to update your -CURRENT, this has been fixed recently. > > robert. that did it, thanks to all :) matheus -- We will call you cygnus, The God of balance you shall be From thompsa at FreeBSD.org Tue Apr 7 16:12:24 2009 From: thompsa at FreeBSD.org (Andrew Thompson) Date: Tue Apr 7 16:12:31 2009 Subject: Booting from usb hard disk In-Reply-To: References: Message-ID: <20090407231218.GC14561@citylink.fud.org.nz> On Sun, Apr 05, 2009 at 03:54:35PM -0300, Nenhum_de_Nos wrote: > On Mon, March 30, 2009 03:10, Andrew Thompson wrote: > > On Tue, Mar 24, 2009 at 03:49:32AM -0500, Robert Noland wrote: > >> On Mon, 2009-03-23 at 19:40 -0300, Nenhum_de_Nos wrote: > >> > I had problem a while ago with via mini itx hardware, that was quite > close. If I try boot from usb (installed in usb hdd), I get to the > >> point > >> > of loader not finding my disk. > >> > > >> > I then used a small flash disk attached to the ata (44 pin ide) > >> channel > >> > and formatted /boot in there. this way I get to the point of mount > >> root > >> > you said, and da0 not being alive soon enough to mount root. list > >> disks > >> > also couldn't find da0 though. > >> > > >> > I tried current from that time, and no good. > >> > > >> > if this is solved, I'll be happy to try whatever patch to current. > (as > >> > long as I can install it from another box/or its ata channel, as it > >> can't > >> > boot vanilla 7.1R) > >> So, my solution was to set kern.cam.scsi_delay=10000 > >> in /boot/loader.conf > > > > The following patch should work. It creates interleaving root hold > tokens from the CAM probe to disk_create and geom providor tasting. I > had to add a malloc type flag as sleeping isnt allowed at the point I > added the token alloc in CAM. > > > > http://people.freebsd.org/~thompsa/root_wait.diff > > > > It needs review by the various geom/cam ppls. > > > > > > Andrew > > phoenix# patch < ../root_wait.diff > Hmm... Looks like a unified diff to me... > The text leading up to this was: > -------------------------- > |Index: kern/vfs_mount.c > |=================================================================== |--- > kern/vfs_mount.c (revision 190540) > |+++ kern/vfs_mount.c (working copy) > -------------------------- > Patching file kern/vfs_mount.c using Plan A... > Reversed (or previously applied) patch detected! Assume -R? [y] The patch was committed and by applying it again you have reverted it. Just use the current sources without the patch. Andrew From kientzle at freebsd.org Tue Apr 7 16:37:25 2009 From: kientzle at freebsd.org (Tim Kientzle) Date: Tue Apr 7 16:37:49 2009 Subject: Hal and KDM breakage (was Re: KDE4 and input events stalled) In-Reply-To: <1239131313.1947.18.camel@balrog.2hip.net> References: <934e1d760904061455o4736d643o1d07e3292192d94c@mail.gmail.com> <1239075455.1908.36.camel@balrog.2hip.net> <49DACDBD.3030809@freebsd.org> <1239077210.1908.39.camel@balrog.2hip.net> <49DAD429.6090309@freebsd.org> <1239078081.1908.41.camel@balrog.2hip.net> <49DAE987.7090802@freebsd.org> <1239086408.35025.59.camel@shumai.marcuscom.com> <20090407185915.GY31409@albert.catwhisker.org> <1239131313.1947.18.camel@balrog.2hip.net> Message-ID: <92cd2ff70904071611r61c895b7g6517a99b286989a0@mail.gmail.com> > > > I tweaked dependencies to force xdm to come up after hald, but even so, > > that didn't help much: it seems that hald isn't really ready to provide > > the services asked of it immediately. > The message "Starting hald" is misleading. Hald doesn't actually start until much, much later. > X will start up, register with dbus and ask for info from hald. If hald > isn't up, or ready it will loop for a bit, waiting. Once hald is up and > registers with dbus it will proceed. At least that is my recollection > of how the code worked. > I waited 15 minutes; screen still dead. Tim From kientzle at freebsd.org Tue Apr 7 16:37:45 2009 From: kientzle at freebsd.org (Tim Kientzle) Date: Tue Apr 7 16:38:05 2009 Subject: Hal and KDM breakage (was Re: KDE4 and input events stalled) In-Reply-To: <49DBA371.3080804@freebsd.org> References: <934e1d760904061455o4736d643o1d07e3292192d94c@mail.gmail.com> <1239075455.1908.36.camel@balrog.2hip.net> <49DACDBD.3030809@freebsd.org> <1239077210.1908.39.camel@balrog.2hip.net> <49DAD429.6090309@freebsd.org> <1239078081.1908.41.camel@balrog.2hip.net> <49DAE987.7090802@freebsd.org> <1239086408.35025.59.camel@shumai.marcuscom.com> <20090407185915.GY31409@albert.catwhisker.org> <49DBA371.3080804@freebsd.org> Message-ID: <92cd2ff70904071637h362da63ua13c1f8eca6fc616@mail.gmail.com> > > See /usr/ports/x11/gdm/files/gdm.in. This is working for GNOME users. > I agree that kdm and xdm should have rc.d scripts. Almost every other system is enabled through rc.conf and kdm and xdm should be the same. But, there's an enormous amount of documentation all over that says to enable kdm or xdm through /etc/ttys. I consider this a real POLA problem. I think that we need to continue to support the /etc/ttys mechanism for a while longer (and add a comment to the stock /etc/ttys to document that xdm/kdm/gdm shouldn't be started that way). I also feel pretty strongly that if kdm/xdm/gdm are all started through rc.d, then we really have to fix the post-/etc/ttys dependency handling. Your scripts are very confusing and basically broken. For example, "REQUIRE: hald" has absolutely no effect. Of course, I'm still confused about why hald has to start after gettys. I thought the whole point of hald was to monitor and publish changes to the system. Why can't it do the same with available consoles? Is there some missing kernel capability that makes this impossible? Or is there an architectural issue with hald that makes this harder than it sounds? Tim From marcus at FreeBSD.org Tue Apr 7 16:43:44 2009 From: marcus at FreeBSD.org (Joe Marcus Clarke) Date: Tue Apr 7 16:43:51 2009 Subject: Hal and KDM breakage (was Re: KDE4 and input events stalled) In-Reply-To: <92cd2ff70904071637h362da63ua13c1f8eca6fc616@mail.gmail.com> References: <934e1d760904061455o4736d643o1d07e3292192d94c@mail.gmail.com> <1239075455.1908.36.camel@balrog.2hip.net> <49DACDBD.3030809@freebsd.org> <1239077210.1908.39.camel@balrog.2hip.net> <49DAD429.6090309@freebsd.org> <1239078081.1908.41.camel@balrog.2hip.net> <49DAE987.7090802@freebsd.org> <1239086408.35025.59.camel@shumai.marcuscom.com> <20090407185915.GY31409@albert.catwhisker.org> <49DBA371.3080804@freebsd.org> <92cd2ff70904071637h362da63ua13c1f8eca6fc616@mail.gmail.com> Message-ID: <1239147806.98664.12.camel@shumai.marcuscom.com> On Tue, 2009-04-07 at 16:37 -0700, Tim Kientzle wrote: > See /usr/ports/x11/gdm/files/gdm.in. This is working for > GNOME users. > > > I agree that kdm and xdm should have rc.d scripts. Almost > every other system is enabled through rc.conf and kdm and > xdm should be the same. > > But, there's an enormous amount of documentation > all over that says to enable kdm or xdm through /etc/ttys. > I consider this a real POLA problem. I think that we > need to continue to support the /etc/ttys mechanism > for a while longer (and add a comment to the stock > /etc/ttys to document that xdm/kdm/gdm shouldn't > be started that way). > > I also feel pretty strongly that if kdm/xdm/gdm are all started > through rc.d, then we really have to fix the post-/etc/ttys > dependency handling. Your scripts are very confusing and > basically broken. For example, "REQUIRE: hald" has absolutely > no effect. Not directly, no. The gdm script does an additional wait to make sure lshal is working. So hald needs to be spawned. > > Of course, I'm still confused about why hald has to start > after gettys. I thought the whole point of hald was to monitor > and publish changes to the system. Why can't it do the > same with available consoles? Is there some missing > kernel capability that makes this impossible? Or is > there an architectural issue with hald that makes this > harder than it sounds? It's not a question of what hal is doing, but rather how console-kit works (and hald depends on console-kit-daemon). It needs to be able to monitor each of the active vtys, but won't work if the vtys haven't been spawned yet. Bland did some work to correct this in -CURRENT, but it won't work on other versions. It was just easier to leave the hack in place. If this could be universally fixed in all supported versions of FreeBSD, then I would be happy to remove the hacks. Joe -- Joe Marcus Clarke FreeBSD GNOME Team :: gnome@FreeBSD.org FreeNode / #freebsd-gnome http://www.FreeBSD.org/gnome -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: This is a digitally signed message part Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20090407/8a0ff3ed/attachment.pgp From kientzle at freebsd.org Tue Apr 7 16:53:08 2009 From: kientzle at freebsd.org (Tim Kientzle) Date: Tue Apr 7 16:53:15 2009 Subject: Hal and KDM breakage (was Re: KDE4 and input events stalled) In-Reply-To: <1239147806.98664.12.camel@shumai.marcuscom.com> References: <934e1d760904061455o4736d643o1d07e3292192d94c@mail.gmail.com> <1239077210.1908.39.camel@balrog.2hip.net> <49DAD429.6090309@freebsd.org> <1239078081.1908.41.camel@balrog.2hip.net> <49DAE987.7090802@freebsd.org> <1239086408.35025.59.camel@shumai.marcuscom.com> <20090407185915.GY31409@albert.catwhisker.org> <49DBA371.3080804@freebsd.org> <92cd2ff70904071637h362da63ua13c1f8eca6fc616@mail.gmail.com> <1239147806.98664.12.camel@shumai.marcuscom.com> Message-ID: <92cd2ff70904071653r4bf3b381lf5de220b2e280c0c@mail.gmail.com> On Tue, Apr 7, 2009 at 4:43 PM, Joe Marcus Clarke wrote: > > It's not a question of what hal is doing, but rather how console-kit > works (and hald depends on console-kit-daemon). It needs to be able to > monitor each of the active vtys... This is the part of the picture I'm still missing. *Why* does hald (via console-kit) care about tracking active vtys? (I presume hald actually doesn't care but that some client of hald needs this information.... ???) .... Bland did some work to correct this in -CURRENT, but it > won't work on other versions. It was just easier to leave the hack in > place. > > If this could be universally fixed in all supported versions of FreeBSD, > then I would be happy to remove the hacks. I'm still curious whether it's feasible to just not monitor the vtys. Tim From randy at psg.com Tue Apr 7 17:22:46 2009 From: randy at psg.com (Randy Bush) Date: Tue Apr 7 17:22:53 2009 Subject: someone is eating massive menory Message-ID: amd64, 4g ram, geom mirror and zfs another amd64 4g system is not crashing but is being very sloggish for 3-5 minutes. work0.psg.com:/root# uname -a FreeBSD work0.psg.com 8.0-CURRENT FreeBSD 8.0-CURRENT #22: Mon Apr 6 01:41:51 UTC 2009 root@work0.psg.com:/usr/obj/usr/src/sys/WORK0 amd64 when midnight crons run, it's death. this is from serial console swap_pager_getswapspace(9): failed swap_pager_getswapspace(3): failed swap_pager_getswapspace(3): failed swap_pager_getswapspace(3): failed swap_pager_getswapspace(3): failed swap_pager_getswapspace(3): failed swap_pager_getswapspace(3): failed swap_pager_getswapspace(3): failed swap_pager_getswapspace(3): failed swap_pager_getswapspace(3): failed swap_pager_getswapspace(3): failed swap_pager_getswapspace(3): failed swap_pager_getswapspace(16): failed swap_pager_getswapspace(3): failed swap_pager_getswapspace(16): failed swap_pager_getswapspace(3): failed swap_pager_getswapspace(3): failed swap_pager_getswapspace(3): failed swap_pager_getswapspace(3): failed /etc/daily.local is pretty st00pid #!/bin/sh # # # reset ipfw filter counts # ipfw -f resetlog ipfw -f zero # # mail and ntp # ( /usr/bin/ntpq -c peers ; echo ; echo ; \ echo irrd mirror requestors ; \ /usr/bin/gunzip -c /var/log/irrd/irrd.log.0.gz \ | for i in `grep 'rror request' | awk '{print $10}' | sort | uniq`; do \ host $i | awk '{print " " $5}'; done \ ; echo ; echo ; \ /usr/local/sbin/eximstats /var/spool/exim/log/main) \ | Mail -s "`hostname` ntp/mail log report" postmaster /usr/local/sbin/exicyclog # # system log # /usr/bin/gunzip -c /var/log/messages.0.gz | \ /usr/bin/egrep -iv '(last message repeated|logfile turned over|PAM: authentication error|reverse map|sshd.*(Did not receive identification string|Disabling protocol|does not map back|(ftp|uucp) not allowed|Invalid user|Failed password|accepted|connection closed|received disconnect|SSH: Server)|sshguard)' | \ /usr/bin/Mail -s "`hostname` System Log" root /usr/bin/gunzip -c /var/log/messages.0.gz | \ /usr/bin/egrep 'sshd.*((ftp|uucp) not allowed|Invalid user|Failed password)|sshguard' | \ /usr/bin/Mail -s "`hostname` attack Log" root # randy From marcus at FreeBSD.org Tue Apr 7 17:27:50 2009 From: marcus at FreeBSD.org (Joe Marcus Clarke) Date: Tue Apr 7 17:27:57 2009 Subject: Hal and KDM breakage (was Re: KDE4 and input events stalled) In-Reply-To: <92cd2ff70904071653r4bf3b381lf5de220b2e280c0c@mail.gmail.com> References: <934e1d760904061455o4736d643o1d07e3292192d94c@mail.gmail.com> <1239077210.1908.39.camel@balrog.2hip.net> <49DAD429.6090309@freebsd.org> <1239078081.1908.41.camel@balrog.2hip.net> <49DAE987.7090802@freebsd.org> <1239086408.35025.59.camel@shumai.marcuscom.com> <20090407185915.GY31409@albert.catwhisker.org> <49DBA371.3080804@freebsd.org> <92cd2ff70904071637h362da63ua13c1f8eca6fc616@mail.gmail.com> <1239147806.98664.12.camel@shumai.marcuscom.com> <92cd2ff70904071653r4bf3b381lf5de220b2e280c0c@mail.gmail.com> Message-ID: <1239150469.98664.18.camel@shumai.marcuscom.com> On Tue, 2009-04-07 at 16:53 -0700, Tim Kientzle wrote: > On Tue, Apr 7, 2009 at 4:43 PM, Joe Marcus Clarke > wrote: > > > It's not a question of what hal is doing, but rather how > console-kit > works (and hald depends on console-kit-daemon). It needs to > be able to > monitor each of the active vtys... > > This is the part of the picture I'm still missing. *Why* does > hald (via console-kit) care about tracking active vtys? > (I presume hald actually doesn't care but that some client > of hald needs this information.... ???) ConsoleKit monitors the vtys for active changes so it can provide consumers such as hal and PolicyKit information about active sessions. In particular, hal uses CK to determine if a user is currently logged in on the console, and if so, allows that user to mount certain volumes that would otherwise not be allowed. > > > .... Bland did some work to correct this in -CURRENT, but it > won't work on other versions. It was just easier to leave the > hack in > place. > > If this could be universally fixed in all supported versions > of FreeBSD, > then I would be happy to remove the hacks. > > I'm still curious whether it's feasible to just not monitor the vtys. Sure, you can try it. Especially if you're not using GNOME, this might be fine. Just remove the hacks from hald's rc.d script. Joe > -- Joe Marcus Clarke FreeBSD GNOME Team :: gnome@FreeBSD.org FreeNode / #freebsd-gnome http://www.FreeBSD.org/gnome -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: This is a digitally signed message part Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20090408/08fc66cf/attachment.pgp From rnoland at FreeBSD.org Tue Apr 7 17:33:47 2009 From: rnoland at FreeBSD.org (Robert Noland) Date: Tue Apr 7 17:33:53 2009 Subject: Hal and KDM breakage (was Re: KDE4 and input events stalled) In-Reply-To: <1239150469.98664.18.camel@shumai.marcuscom.com> References: <934e1d760904061455o4736d643o1d07e3292192d94c@mail.gmail.com> <1239077210.1908.39.camel@balrog.2hip.net> <49DAD429.6090309@freebsd.org> <1239078081.1908.41.camel@balrog.2hip.net> <49DAE987.7090802@freebsd.org> <1239086408.35025.59.camel@shumai.marcuscom.com> <20090407185915.GY31409@albert.catwhisker.org> <49DBA371.3080804@freebsd.org> <92cd2ff70904071637h362da63ua13c1f8eca6fc616@mail.gmail.com> <1239147806.98664.12.camel@shumai.marcuscom.com> <92cd2ff70904071653r4bf3b381lf5de220b2e280c0c@mail.gmail.com> <1239150469.98664.18.camel@shumai.marcuscom.com> Message-ID: <1239150776.1947.28.camel@balrog.2hip.net> On Tue, 2009-04-07 at 20:27 -0400, Joe Marcus Clarke wrote: > On Tue, 2009-04-07 at 16:53 -0700, Tim Kientzle wrote: > > On Tue, Apr 7, 2009 at 4:43 PM, Joe Marcus Clarke > > wrote: > > > > > > It's not a question of what hal is doing, but rather how > > console-kit > > works (and hald depends on console-kit-daemon). It needs to > > be able to > > monitor each of the active vtys... > > > > This is the part of the picture I'm still missing. *Why* does > > hald (via console-kit) care about tracking active vtys? > > (I presume hald actually doesn't care but that some client > > of hald needs this information.... ???) > > ConsoleKit monitors the vtys for active changes so it can provide > consumers such as hal and PolicyKit information about active sessions. > In particular, hal uses CK to determine if a user is currently logged in > on the console, and if so, allows that user to mount certain volumes > that would otherwise not be allowed. > > > > > > > .... Bland did some work to correct this in -CURRENT, but it > > won't work on other versions. It was just easier to leave the > > hack in > > place. > > > > If this could be universally fixed in all supported versions > > of FreeBSD, > > then I would be happy to remove the hacks. > > > > I'm still curious whether it's feasible to just not monitor the vtys. > > Sure, you can try it. Especially if you're not using GNOME, this might > be fine. Just remove the hacks from hald's rc.d script. I wonder if it might be sane to check for enable_gnome="YES" to delay... robert. > Joe > > > -- Robert Noland FreeBSD -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 196 bytes Desc: This is a digitally signed message part Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20090408/4f9f9ded/attachment.pgp From bruce at cran.org.uk Tue Apr 7 17:44:25 2009 From: bruce at cran.org.uk (Bruce Cran) Date: Tue Apr 7 17:44:31 2009 Subject: AMD Opteron CPU PMC patch In-Reply-To: <4451ccf20904061110m91da3del8d39d81132a4dc48@mail.gmail.com> References: <4451ccf20904061110m91da3del8d39d81132a4dc48@mail.gmail.com> Message-ID: <20090408014415.4e709a21@gluon.draftnet> On Tue, 7 Apr 2009 02:10:24 +0800 ??ccuiyyan@sina.com wrote: > Hi all : > > Are there any patches available in FreeBSD-current 8.0 for AMD > Opteron > > > CPU to support PMC? According to http://wiki.freebsd.org/PmcTools/PmcHardware Opteron should already be supported. Do you get errors when you load hwpmc? -- Bruce Cran From debardeleben at aol.com Tue Apr 7 19:02:18 2009 From: debardeleben at aol.com (debardeleben@aol.com) Date: Tue Apr 7 19:02:25 2009 Subject: xorg loops In-Reply-To: <1239129677.1947.14.camel@balrog.2hip.net> References: <49D8D03B.8090302@arcor.de><3a142e750904050919l1388b559t9bbd751546e239e7@mail.gmail.com><1238957462.1829.8.camel@balrog.2hip.net> <49D90363.6010602@arcor.de><1238959921.1829.10.camel@balrog.2hip.net><49DB573C.3020703@FreeBSD.org> <1239129677.1947.14.camel@balrog.2hip.net> Message-ID: <8CB8605286047C4-E6C-1456@WEBMAIL-MB18.sysops.aol.com> Does anyone understand the method the putting Xorg's keyboard and mouse configuration in HAL? The only thing I can figure is its some kind of hot-plug support for keymaps. I guess I do not understand the point because it seams as though these items are physically connected with a screen, and may as well be static configured. It seams to me as though everyone has become over enamored with dynamic configuration in general. I kind of prefer a static configuration for the permanently configuration of a system. It seams that this results in faster boot, better and more consistent error messages when the expected configuration is not found. I think this X input fiasco really illustrates what I mean. Additionally, hald is currently not nearly robust enough to count on as much as we are now. On my system hald and GEOM have conspired to not only lose both original and back up copies of important data by "automagically" and incorrectly mounting disks not intended to be mounted. In addition, it falls over if volume labels are not as expected. Both hald and GEOM do not behave well if labels are not as expected. Hal tends to dumb core, GEOM seams to like to get into a state where all of the tools fail with "unexpected error", making it very difficult to fix. One of my disks is particularly problematic in that it normally has a UFS label. But every once and a while, the UFS label is corrupted (see hald doing unwanted mounts) in which case GEOM decides that there is a msdosfs label with some binary value. This binary label then almost certainly confuses HAL. Windows doesnt see the disk because the partition type is 165. Its not that I expect stuff to work with corrupt data, but central system tools like hald and GEOM need to be robust enough to report errors and keep providing service. Not dump core and interfering with other functions of the system. Right now, the misidentified UFS fileystem is causing access to hal to hang for 30 seconds, then report an error. This causes Xorg and? components of gnome to start very slow, then fail. Here is what lshal produces: nat% lshal *** [DIE] lshal.c:dump_devices():285 : Couldn't obtain list of devices Stuff found in my log. Apr? 7 08:11:39 nat hald[1482]: 08:11:39.486 [I] hald.c:108: Added device to GDL; udi=/org/freedesktop/Hal/devices/volume_part2_size_81956657664 Apr? 7 08:11:39 nat hald[1482]: 08:11:39.486 [W] device.c:215: Property has invalid UTF-8 string '/dev/msdosfs/M-^[^U\xe9M-^O\xfeuO\xbexM-^M\xed', it was changed to: '/dev/msdosfs/?^U???uO?x??' Apr? 7 08:11:39 nat hald[1482]: 08:11:39.486 [W] hf-block.c:49: unable to stat /dev/msdosfs/?^U???uO?x??: No such file or directory Apr? 7 08:11:39 nat hald[1482]: 08:11:39.496 [I] hald.c:108: Added device to GDL; udi=/org/freedesktop/Hal/devices/volume_part2_size_81956657664_block Note that this disk had a UFS filesystem on it, not dosfs. Enough ranting for now, but bottom line, I think we nay be moving towards too much mysterious complicated automatic configuration. It is starting to feel as though we are starting to emulate some of the worst features of windows. Automatic is not necessarily better, even if it gets it right. When wrong its a disaster. -Charles -----Original Message----- From: Robert Noland To: Alex Dupre Cc: freebsd-current@freebsd.org Sent: Tue, 7 Apr 2009 11:41 am Subject: Re: xorg loops On Tue, 2009-04-07 at 15:38 +0200, Alex Dupre wrote: > Robert Noland ha scritto: > > hald should work fine with moused now. > > As you wrote in the UPDATING: > > "Use of AllowEmptyInput should no longer > be needed for most users and moused should now work fine." > > I think "most" != "all" users, in fact my current up-to-date workstation > still needs AllowEmptyInput to work. hal-device doesn't list any mouse > at all. Is there anything I can do to help improving the situation? The root of the issue is that there are just too many ways to configure input devices... Particularly mice. Marcus, jkim and I have tried to make accommodations for all of the cases, but it gets rather tricky. Users can have mice configured using psm0, ums0, (serial even), moused and we have to be able to figure out if they are statically configured in X or not, based on whether or not X has already opened one of the file descriptors. Based on analyzing all of that, we decide whether or not to advertise to X that it should attach the device. If you are using moused, then hald *should* recognize that and advertise /dev/sysmouse to X. Additional input devices, get added via moused and hald knows that /dev/sysmouse is already opened by X, so it shouldn't re-advertise the same port again. We desperately need to simplify our input layer, but I'm not certain exactly what the right answer is. robert. -- Robert Noland FreeBSD From pyunyh at gmail.com Tue Apr 7 19:48:10 2009 From: pyunyh at gmail.com (Pyun YongHyeon) Date: Tue Apr 7 19:48:16 2009 Subject: axe(4) (Belkin F5D5055) problems In-Reply-To: <2e77fc10904071315q66d725bl76229d9bffd92f35@mail.gmail.com> References: <75656435-49E2-457A-9CFE-8706CD44916E@gmail.com> <20090328080924.GD99923@michelle.cdnetworks.co.kr> <2e77fc10903280259s5a761cacs398b88649a2367fe@mail.gmail.com> <20090328102735.GE99923@michelle.cdnetworks.co.kr> <2e77fc10903280942u7c934aa4w80176680e9dff6d7@mail.gmail.com> <2e77fc10903281539h7b713711w116a90fd2bfadbcf@mail.gmail.com> <20090330021648.GE7076@michelle.cdnetworks.co.kr> <20090330024748.GF7076@michelle.cdnetworks.co.kr> <2e77fc10904071315q66d725bl76229d9bffd92f35@mail.gmail.com> Message-ID: <20090408024901.GC37714@michelle.cdnetworks.co.kr> On Tue, Apr 07, 2009 at 11:15:47PM +0300, Niki Denev wrote: [...] I've read the datasheet but I still don't understand why dsp programming in truephy_reset is required. Anyway would you try attached patch? And show me dmesg output generated by truephy(4). > I have temporarily replaced the belkin USB ethernet interface with an > Apple USB ethernet, > which also uses the axe(4) driver, but is only 100Mbit/s. > As I suspected the negotiation problems do not exist with it, and > everything seemed ok, until > it started to stop working exactly like the previous adapter. > Pings start to return "buffer space not available" and replugging or > "usbconfig reset" the interface > returns it to normal status. > This sounds like different issue to me. Let's focus on the truephy(4) until axe(4) get a valid link report. > It looks like that the packet loss that I've experienced with the > Belkin gigabit adabter is one problem, > and the interface stopping to work another. > > P.S.: I don't know if it could be my USB hardware, because the machine > is a little bit "exotic", > an HP ex470 MediaSmartServer, which was supposedly designed to run > only embedded version of > Windows and has a nasty SiS chipset in it (with the unsupported sis191 > gigabit adapter) There had been a post for SiS191 driver. Check mailing list archives. Unfortunately I don't have SiS191 controller so I couldn't write a driver and commit the posted driver to tree. Even though the controller is not for high performance servers it would be enough to most desktop users. At least SiS controllers does not seem to require special workarounds for silicon bugs which are commonly found on RealTek/Marvell controllers. Alternatively you can use ndis(4) to use your SiS191 controller. I don't know whether ndis(4) works for this controller though. -------------- next part -------------- Index: sys/dev/mii/truephy.c =================================================================== --- sys/dev/mii/truephy.c (revision 190834) +++ sys/dev/mii/truephy.c (working copy) @@ -66,6 +66,11 @@ static void truephy_reset(struct mii_softc *); static void truephy_status(struct mii_softc *); +struct truephy_softc { + struct mii_softc mii_sc; + int mii_model; +}; + static device_method_t truephy_methods[] = { /* device interface */ DEVMETHOD(device_probe, truephy_probe), @@ -76,6 +81,7 @@ }; static const struct mii_phydesc truephys[] = { + MII_PHY_DESC(AGERE, ET1011C_1), MII_PHY_DESC(AGERE, ET1011C), MII_PHY_END }; @@ -85,7 +91,7 @@ static driver_t truephy_driver = { "truephy", truephy_methods, - sizeof(struct mii_softc) + sizeof(struct truephy_softc) }; DRIVER_MODULE(truephy, miibus, truephy_driver, truephy_devclass, 0, 0); @@ -139,15 +145,15 @@ truephy_attach(device_t dev) { struct mii_softc *sc; + struct truephy_softc *tsc; struct mii_attach_args *ma; struct mii_data *mii; - sc = device_get_softc(dev); + tsc = device_get_softc(dev); + sc = &tsc->mii_sc; ma = device_get_ivars(dev); sc->mii_phy = ma->mii_phyno; - if (sc->mii_anegticks == 0) - sc->mii_anegticks = MII_ANEGTICKS; sc->mii_dev = device_get_parent(dev); mii = device_get_softc(sc->mii_dev); LIST_INSERT_HEAD(&mii->mii_phys, sc, mii_list); @@ -161,13 +167,17 @@ mii->mii_instance++; + tsc->mii_model = MII_MODEL(ma->mii_id2); + truephy_reset(sc); sc->mii_capabilities = PHY_READ(sc, MII_BMSR) & ma->mii_capmask; if (sc->mii_capabilities & BMSR_EXTSTAT) { sc->mii_extcapabilities = PHY_READ(sc, MII_EXTSR); - /* No 1000baseT half-duplex support */ - sc->mii_extcapabilities &= ~EXTSR_1000THDX; + if (tsc->mii_model == MII_MODEL_AGERE_ET1011C) { + /* No 1000baseT half-duplex support */ + sc->mii_extcapabilities &= ~EXTSR_1000THDX; + } } device_printf(dev, " "); @@ -185,6 +195,7 @@ static int truephy_service(struct mii_softc *sc, struct mii_data *mii, int cmd) { + struct truephy_softc *tsc = (struct truephy_softc *)sc; struct ifmedia_entry *ife = mii->mii_media.ifm_cur; int bmcr; @@ -214,22 +225,29 @@ if ((mii->mii_ifp->if_flags & IFF_UP) == 0) break; - if (IFM_SUBTYPE(ife->ifm_media) != IFM_AUTO) { - bmcr = PHY_READ(sc, MII_BMCR) & ~BMCR_AUTOEN; - PHY_WRITE(sc, MII_BMCR, bmcr); - PHY_WRITE(sc, MII_BMCR, bmcr | BMCR_PDOWN); - } + switch (tsc->mii_model) { + case MII_MODEL_AGERE_ET1011C: + if (IFM_SUBTYPE(ife->ifm_media) != IFM_AUTO) { + bmcr = PHY_READ(sc, MII_BMCR) & ~BMCR_AUTOEN; + PHY_WRITE(sc, MII_BMCR, bmcr); + PHY_WRITE(sc, MII_BMCR, bmcr | BMCR_PDOWN); + } - mii_phy_setmedia(sc); + mii_phy_setmedia(sc); - if (IFM_SUBTYPE(ife->ifm_media) != IFM_AUTO) { - bmcr = PHY_READ(sc, MII_BMCR) & ~BMCR_PDOWN; - PHY_WRITE(sc, MII_BMCR, bmcr); + if (IFM_SUBTYPE(ife->ifm_media) != IFM_AUTO) { + bmcr = PHY_READ(sc, MII_BMCR) & ~BMCR_PDOWN; + PHY_WRITE(sc, MII_BMCR, bmcr); - if (IFM_SUBTYPE(ife->ifm_media) == IFM_1000_T) { - PHY_WRITE(sc, MII_BMCR, - bmcr | BMCR_AUTOEN | BMCR_STARTNEG); + if (IFM_SUBTYPE(ife->ifm_media) == IFM_1000_T) { + PHY_WRITE(sc, MII_BMCR, + bmcr | BMCR_AUTOEN | BMCR_STARTNEG); + } } + break; + default: + mii_phy_setmedia(sc); + break; } break; @@ -256,8 +274,14 @@ static void truephy_reset(struct mii_softc *sc) { + struct truephy_softc *tsc; int i; + tsc = (struct truephy_softc *)sc; + if (tsc->mii_model != MII_MODEL_AGERE_ET1011C) { + mii_phy_reset(sc); + return; + } for (i = 0; i < 2; ++i) { PHY_READ(sc, MII_PHYIDR1); PHY_READ(sc, MII_PHYIDR2); @@ -325,6 +349,15 @@ if (bmsr & BMSR_LINK) mii->mii_media_status |= IFM_ACTIVE; + if (bmcr & BMCR_ISO) { + mii->mii_media_active |= IFM_NONE; + mii->mii_media_status = 0; + return; + } + + if (bmcr & BMCR_LOOP) + mii->mii_media_active |= IFM_LOOP; + if (bmcr & BMCR_AUTOEN) { if ((bmsr & BMSR_ACOMP) == 0) { mii->mii_media_active |= IFM_NONE; @@ -332,6 +365,12 @@ } } + if (sr & TRUEPHY_SR_SBY) { + /* PHY is in standby mode. */ + mii->mii_media_active |= IFM_NONE; + return; + } + switch (sr & TRUEPHY_SR_SPD_MASK) { case TRUEPHY_SR_SPD_1000T: mii->mii_media_active |= IFM_1000_T; Index: sys/dev/mii/truephyreg.h =================================================================== --- sys/dev/mii/truephyreg.h (revision 190834) +++ sys/dev/mii/truephyreg.h (working copy) @@ -55,6 +55,7 @@ #define TRUEPHY_CONF_TXFIFO_32 0x3000 #define TRUEPHY_SR 0x1a +#define TRUEPHY_SR_SBY 0x8000 #define TRUEPHY_SR_SPD_MASK 0x0300 #define TRUEPHY_SR_SPD_1000T 0x0200 #define TRUEPHY_SR_SPD_100TX 0x0100 Index: sys/dev/mii/miidevs =================================================================== --- sys/dev/mii/miidevs (revision 190834) +++ sys/dev/mii/miidevs (working copy) @@ -109,6 +109,7 @@ */ /* Agere Systems PHYs */ +model AGERE ET1011C_1 0x0001 ET1011C 10/100/1000baseT PHY model AGERE ET1011C 0x0004 ET1011C 10/100/1000baseT PHY /* Altima Communications PHYs */ From weongyo.jeong at gmail.com Tue Apr 7 19:48:20 2009 From: weongyo.jeong at gmail.com (Weongyo Jeong) Date: Tue Apr 7 19:48:26 2009 Subject: [head tinderbox] failure on ia64/ia64 In-Reply-To: <20090407200602.75DA37302F@freebsd-current.sentex.ca> References: <20090407200602.75DA37302F@freebsd-current.sentex.ca> Message-ID: <20090408024806.GA77502@weongyo.cdnetworks.kr> On Tue, Apr 07, 2009 at 04:06:02PM -0400, FreeBSD Tinderbox wrote: > TB --- 2009-04-07 18:16:46 - tinderbox 2.6 running on freebsd-current.sentex.ca > TB --- 2009-04-07 18:16:46 - starting HEAD tinderbox run for ia64/ia64 > TB --- 2009-04-07 18:16:46 - cleaning the object tree > TB --- 2009-04-07 18:17:06 - cvsupping the source tree > TB --- 2009-04-07 18:17:06 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/ia64/ia64/supfile > TB --- 2009-04-07 18:17:18 - building world > TB --- 2009-04-07 18:17:18 - MAKEOBJDIRPREFIX=/obj > TB --- 2009-04-07 18:17:18 - PATH=/usr/bin:/usr/sbin:/bin:/sbin > TB --- 2009-04-07 18:17:18 - TARGET=ia64 > TB --- 2009-04-07 18:17:18 - TARGET_ARCH=ia64 > TB --- 2009-04-07 18:17:18 - TZ=UTC > TB --- 2009-04-07 18:17:18 - __MAKE_CONF=/dev/null > TB --- 2009-04-07 18:17:18 - cd /src > TB --- 2009-04-07 18:17:18 - /usr/bin/make -B buildworld > >>> World build started on Tue Apr 7 18:17:19 UTC 2009 > >>> Rebuilding the temporary build tree > >>> stage 1.1: legacy release compatibility shims > >>> stage 1.2: bootstrap tools > >>> stage 2.1: cleaning up the object tree > >>> stage 2.2: rebuilding the object tree > >>> stage 2.3: build tools > >>> stage 3: cross tools > >>> stage 4.1: building includes > >>> stage 4.2: building libraries > >>> stage 4.3: make dependencies > >>> stage 4.4: building everything > [...] > ===> usr.sbin/tzsetup (all) > cc -O2 -pipe -I/src/usr.sbin/tzsetup -std=gnu99 -c /src/usr.sbin/tzsetup/tzsetup.c > cc -O2 -pipe -I/src/usr.sbin/tzsetup -std=gnu99 -o tzsetup tzsetup.o -ldialog -lncurses > gzip -cn /src/usr.sbin/tzsetup/tzsetup.8 > tzsetup.8.gz > ===> usr.sbin/uathload (all) > cc -O2 -pipe -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wunused-parameter -Wno-uninitialized -Wno-pointer-sign -c /src/usr.sbin/uathload/uathload.c > ld -b binary -d -warn-common -r -d -o ar5523.o ar5523.bin > ld: failed to merge target specific data of file ar5523.bin > *** Error code 1 It looks it's my mistake but I don't know why it happens on only ia64. Please let me know if you have a solution. I'd try to disable build of uathload on ia64 temporarily. regards, Weongyo Jeong From xcllnt at mac.com Tue Apr 7 20:10:55 2009 From: xcllnt at mac.com (Marcel Moolenaar) Date: Tue Apr 7 20:11:02 2009 Subject: [head tinderbox] failure on ia64/ia64 In-Reply-To: <20090408024806.GA77502@weongyo.cdnetworks.kr> References: <20090407200602.75DA37302F@freebsd-current.sentex.ca> <20090408024806.GA77502@weongyo.cdnetworks.kr> Message-ID: <6CBEFC47-41FC-45DE-B537-38069C3F88E4@mac.com> On Apr 7, 2009, at 7:48 PM, Weongyo Jeong wrote: >> ===> usr.sbin/uathload (all) >> cc -O2 -pipe -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format- >> y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing- >> prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite- >> strings -Wswitch -Wshadow -Wcast-align -Wunused-parameter -Wno- >> uninitialized -Wno-pointer-sign -c /src/usr.sbin/uathload/uathload.c >> ld -b binary -d -warn-common -r -d -o ar5523.o ar5523.bin >> ld: failed to merge target specific data of file ar5523.bin >> *** Error code 1 > > It looks it's my mistake but I don't know why it happens on only ia64. > Please let me know if you have a solution. The problem is that binutils expects machine-specific flags to match. These machine-specific flags are in the ELF header and ar5523.o has them. Howeber, ar5523.bin does not. They end up being different because of that and the linker refuse to link "object" files with different machine-specific flags. > I'd try to disable build of uathload on ia64 temporarily. That's best. Thanks! -- Marcel Moolenaar xcllnt@mac.com From scottl at samsco.org Tue Apr 7 20:28:08 2009 From: scottl at samsco.org (Scott Long) Date: Tue Apr 7 20:28:15 2009 Subject: Root mount fails again. CAM related? In-Reply-To: <74181BF8-E111-4208-8C3E-8F1B39808E0B@mac.com> References: <24C524FA-2D87-4A0E-97B7-4D7C832B3E72@mac.com> <74181BF8-E111-4208-8C3E-8F1B39808E0B@mac.com> Message-ID: <49DC19C3.1000702@samsco.org> Marcel Moolenaar wrote: > > On Apr 7, 2009, at 11:22 AM, pluknet wrote: > >>> My ARM board boots from a USB mass storage device and >>> for the second time the the root mount fails. First is >>> was because the root mount wouldn't wait for the USB >>> stack to complete the discovery process. Now CAM seems >>> to have entered the picture: >>> > >> Can this be a similar one? That was committed not far ago in rev. 190676. >> http://lists.freebsd.org/pipermail/freebsd-current/2009-April/005635.html > > It could be the cause of the problem. Things worked fine > before CAM grew calls to root_mount_hold()... > Feel free to back the change out of CAM. I don't have time to go through and explain why it was a poor idea in the first place, nor to figure out what in USB is broken. Scott From fjwcash at gmail.com Tue Apr 7 22:11:29 2009 From: fjwcash at gmail.com (Freddie Cash) Date: Tue Apr 7 22:11:35 2009 Subject: Hal and KDM breakage (was Re: KDE4 and input events stalled) In-Reply-To: <49DBA371.3080804@freebsd.org> References: <934e1d760904061455o4736d643o1d07e3292192d94c@mail.gmail.com> <1239075455.1908.36.camel@balrog.2hip.net> <49DACDBD.3030809@freebsd.org> <1239077210.1908.39.camel@balrog.2hip.net> <49DAD429.6090309@freebsd.org> <1239078081.1908.41.camel@balrog.2hip.net> <49DAE987.7090802@freebsd.org> <1239086408.35025.59.camel@shumai.marcuscom.com> <20090407185915.GY31409@albert.catwhisker.org> <49DBA371.3080804@freebsd.org> Message-ID: On Tue, Apr 7, 2009 at 12:03 PM, Joe Marcus Clarke wrote: > See /usr/ports/x11/gdm/files/gdm.in. ?This is working for GNOME users. For the interested, here's a hacked together kdm4 script, using the gdm.in above as a basis. It works here, although that isn't really saying much. :) I called it kdm4 to differentiate it from kdm from kdebase3: #!/bin/sh # PROVIDE: kdm # REQUIRE: LOGIN cleanvar moused syscons dbus hald # # Add the following to /etc/rc.conf to start KDM 4.x at boot time: # # kdm4_enable="YES" # . /etc/rc.subr kdm4_enable=${kdm4_enable-no} export PATH=/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/kde4/bin:/usr/local/bin:/usr/local/sbin name="kdm" rcvar=`set_rcvar` command="/usr/local/kde4/bin/${name}" procname="/usr/local/kde4/bin/${name}-bin" pidfile="/var/run/${name}.pid" start_cmd="kdm_start" kdm_start() { echo "Starting ${name}." ( iter=0 while ! ps -axoargs | grep "^/usr/libexec/getty " | grep -qv grep >/dev/null 2>&1; do if [ ${iter} -eq 60 ]; then break fi sleep 1 iter=$(expr ${iter} + 1) done iter=0 while ! /usr/local/bin/lshal >/dev/null 2>&1 ; do if [ ${iter} -eq 60 ]; then break fi sleep 1 iter=$(expr ${iter} + 1) done ${command} ${kdm_flags} ) & } load_rc_config ${name} run_rc_command "$1" -- Freddie Cash fjwcash@gmail.com From fjwcash at gmail.com Tue Apr 7 22:14:47 2009 From: fjwcash at gmail.com (Freddie Cash) Date: Tue Apr 7 22:14:56 2009 Subject: Hal and KDM breakage (was Re: KDE4 and input events stalled) In-Reply-To: <1239150469.98664.18.camel@shumai.marcuscom.com> References: <934e1d760904061455o4736d643o1d07e3292192d94c@mail.gmail.com> <1239078081.1908.41.camel@balrog.2hip.net> <49DAE987.7090802@freebsd.org> <1239086408.35025.59.camel@shumai.marcuscom.com> <20090407185915.GY31409@albert.catwhisker.org> <49DBA371.3080804@freebsd.org> <92cd2ff70904071637h362da63ua13c1f8eca6fc616@mail.gmail.com> <1239147806.98664.12.camel@shumai.marcuscom.com> <92cd2ff70904071653r4bf3b381lf5de220b2e280c0c@mail.gmail.com> <1239150469.98664.18.camel@shumai.marcuscom.com> Message-ID: On Tue, Apr 7, 2009 at 5:27 PM, Joe Marcus Clarke wrote: > On Tue, 2009-04-07 at 16:53 -0700, Tim Kientzle wrote: >> On Tue, Apr 7, 2009 at 4:43 PM, Joe Marcus Clarke >> wrote: >> >> >> ? ? ? ? It's not a question of what hal is doing, but rather how >> ? ? ? ? console-kit >> ? ? ? ? works (and hald depends on console-kit-daemon). ?It needs to >> ? ? ? ? be able to >> ? ? ? ? monitor each of the active vtys... >> >> This is the part of the picture I'm still missing. ?*Why* does >> hald (via console-kit) care about tracking active vtys? >> (I presume hald actually doesn't care but that some client >> of hald needs this information.... ???) > > ConsoleKit monitors the vtys for active changes so it can provide > consumers such as hal and PolicyKit information about active sessions. > In particular, hal uses CK to determine if a user is currently logged in > on the console, and if so, allows that user to mount certain volumes > that would otherwise not be allowed. > >> >> >> ? ? ? ? .... ?Bland did some work to correct this in -CURRENT, but it >> ? ? ? ? won't work on other versions. ?It was just easier to leave the >> ? ? ? ? hack in >> ? ? ? ? place. >> >> ? ? ? ? If this could be universally fixed in all supported versions >> ? ? ? ? of FreeBSD, >> ? ? ? ? then I would be happy to remove the hacks. >> >> I'm still curious whether it's feasible to just not monitor the vtys. > > Sure, you can try it. ?Especially if you're not using GNOME, this might > be fine. ?Just remove the hacks from hald's rc.d script. Doesn't work, at least not in my quick-n-dirty testing, using the kdm4 script I just posted. If you remove the lshal checks, then the keyboard doesn't work once kdm starts. -- Freddie Cash fjwcash@gmail.com From sepherosa at gmail.com Tue Apr 7 22:41:19 2009 From: sepherosa at gmail.com (Sepherosa Ziehau) Date: Tue Apr 7 22:41:30 2009 Subject: axe(4) (Belkin F5D5055) problems In-Reply-To: <20090408024901.GC37714@michelle.cdnetworks.co.kr> References: <75656435-49E2-457A-9CFE-8706CD44916E@gmail.com> <2e77fc10903280259s5a761cacs398b88649a2367fe@mail.gmail.com> <20090328102735.GE99923@michelle.cdnetworks.co.kr> <2e77fc10903280942u7c934aa4w80176680e9dff6d7@mail.gmail.com> <2e77fc10903281539h7b713711w116a90fd2bfadbcf@mail.gmail.com> <20090330021648.GE7076@michelle.cdnetworks.co.kr> <20090330024748.GF7076@michelle.cdnetworks.co.kr> <2e77fc10904071315q66d725bl76229d9bffd92f35@mail.gmail.com> <20090408024901.GC37714@michelle.cdnetworks.co.kr> Message-ID: On Wed, Apr 8, 2009 at 10:49 AM, Pyun YongHyeon wrote: > On Tue, Apr 07, 2009 at 11:15:47PM +0300, Niki Denev wrote: > > [...] > > I've read the datasheet but I still don't understand why dsp > programming in truephy_reset is required. Anyway would you try I copied the mysterious code sequence from Agere's Linux driver. It is not mentioned anywhere in the datasheet. Best Regards, sephe -- Live Free or Die From tinderbox at freebsd.org Tue Apr 7 22:46:28 2009 From: tinderbox at freebsd.org (FreeBSD Tinderbox) Date: Tue Apr 7 22:46:46 2009 Subject: [head tinderbox] failure on ia64/ia64 Message-ID: <20090408054623.B214B7302F@freebsd-current.sentex.ca> TB --- 2009-04-08 03:57:00 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2009-04-08 03:57:00 - starting HEAD tinderbox run for ia64/ia64 TB --- 2009-04-08 03:57:00 - cleaning the object tree TB --- 2009-04-08 03:57:30 - cvsupping the source tree TB --- 2009-04-08 03:57:30 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/ia64/ia64/supfile TB --- 2009-04-08 03:57:38 - building world TB --- 2009-04-08 03:57:38 - MAKEOBJDIRPREFIX=/obj TB --- 2009-04-08 03:57:38 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-04-08 03:57:38 - TARGET=ia64 TB --- 2009-04-08 03:57:38 - TARGET_ARCH=ia64 TB --- 2009-04-08 03:57:38 - TZ=UTC TB --- 2009-04-08 03:57:38 - __MAKE_CONF=/dev/null TB --- 2009-04-08 03:57:38 - cd /src TB --- 2009-04-08 03:57:38 - /usr/bin/make -B buildworld >>> World build started on Wed Apr 8 03:57:40 UTC 2009 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything [...] ===> usr.sbin/tzsetup (all) cc -O2 -pipe -I/src/usr.sbin/tzsetup -std=gnu99 -c /src/usr.sbin/tzsetup/tzsetup.c cc -O2 -pipe -I/src/usr.sbin/tzsetup -std=gnu99 -o tzsetup tzsetup.o -ldialog -lncurses gzip -cn /src/usr.sbin/tzsetup/tzsetup.8 > tzsetup.8.gz ===> usr.sbin/uathload (all) cc -O2 -pipe -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wunused-parameter -Wno-uninitialized -Wno-pointer-sign -c /src/usr.sbin/uathload/uathload.c ld -b binary -d -warn-common -r -d -o ar5523.o ar5523.bin ld: failed to merge target specific data of file ar5523.bin *** Error code 1 Stop in /src/usr.sbin/uathload. *** Error code 1 Stop in /src/usr.sbin. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-04-08 05:46:23 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-04-08 05:46:23 - ERROR: failed to build world TB --- 2009-04-08 05:46:23 - 5316.77 user 391.94 system 6563.02 real http://tinderbox.des.no/tinderbox-head-HEAD-ia64-ia64.full From kientzle at freebsd.org Tue Apr 7 23:12:45 2009 From: kientzle at freebsd.org (Tim Kientzle) Date: Tue Apr 7 23:13:16 2009 Subject: Hal and KDM breakage (was Re: KDE4 and input events stalled) In-Reply-To: References: <934e1d760904061455o4736d643o1d07e3292192d94c@mail.gmail.com> <1239078081.1908.41.camel@balrog.2hip.net> <49DAE987.7090802@freebsd.org> <1239086408.35025.59.camel@shumai.marcuscom.com> <20090407185915.GY31409@albert.catwhisker.org> <49DBA371.3080804@freebsd.org> <92cd2ff70904071637h362da63ua13c1f8eca6fc616@mail.gmail.com> <1239147806.98664.12.camel@shumai.marcuscom.com> <92cd2ff70904071653r4bf3b381lf5de220b2e280c0c@mail.gmail.com> <1239150469.98664.18.camel@shumai.marcuscom.com> Message-ID: <49DC405B.7090208@freebsd.org> >>> I'm still curious whether it's feasible to just not monitor the vtys. >> Sure, you can try it. Especially if you're not using GNOME, this might >> be fine. Just remove the hacks from hald's rc.d script. I think I finally understand the issue here. Basically, there seem to be two options: Option 1: Comment out this line from /usr/local/etc/rc.d/hald #start_cmd="hald_start" After this change, the rc.d/hald script will start hald immediately, so that hald will be running before /etc/ttys is processed. This allows KDM/xdm/gdm to be started either from /etc/ttys or from a very simple rc.d script (in particular, the 'lshal' and 'getty' checks are not necessary in this case). The risk with this approach is that hald on 7-STABLE and earlier may be unable to detect whether the user is local or using a remote X terminal, and hence the auto-mount features of KDE and Gnome may not function properly. On FreeBSD-CURRENT, this should be fine and everything should work properly. Option 2: Use the current hald script as-is. With this, the rc.d/hald script sets up a background process that will start hald only after /etc/ttys has been processed. As a result, KDM cannot be started in the traditional fashion from /etc/ttys because KDM cannot be started before hald. (Although Robert claims this should work...) In this case, KDM can only be started from an rc.d script, and that rc.d script needs to use some variant of the "lshal" hack to ensure that KDM won't start before hald. The advantage of this approach is that auto-mount should function correctly in KDE and Gnome, even on 7-STABLE and earlier. Joe: Did I get this right? Freddie Cash pointed out: > Doesn't work, at least not in my quick-n-dirty testing, using the kdm4 > script I just posted. If you remove the lshal checks, then the > keyboard doesn't work once kdm starts. Freddie: If you remove the lshal checks from the kdm startup script, then you have to also remove the hald_start call from the hald startup script. Otherwise, kdm will start before hald and bad things will happen (keyboard/mouse failures at a minimum; I get a complete black screen in this case). Tim From hselasky at c2i.net Tue Apr 7 23:13:41 2009 From: hselasky at c2i.net (Hans Petter Selasky) Date: Tue Apr 7 23:13:48 2009 Subject: new usb: mass storage error, Synchronize cache failed In-Reply-To: <747dc8f30904071139j32b55e2pf0fcd07a51c260a2@mail.gmail.com> References: <747dc8f30904071139j32b55e2pf0fcd07a51c260a2@mail.gmail.com> Message-ID: <200904080816.09996.hselasky@c2i.net> On Tuesday 07 April 2009, Renato Botelho wrote: > When I plug a gradiente cell phone on my USB I got this: > > Apr 7 15:33:01 botelhor root: Unknown USB device: vendor 0x0e8d > product 0x0002 bus uhub0 > Apr 7 15:33:01 botelhor kernel: ugen0.2: at usbus0 > Apr 7 15:33:01 botelhor kernel: umass0: on usbus0 > Apr 7 15:33:01 botelhor kernel: umass0: SCSI over Bulk-Only; quirks = > 0x0000 Apr 7 15:33:02 botelhor kernel: umass0:0:0:-1: Attached to scbus0 > Apr 7 15:33:02 botelhor kernel: da0 at umass-sim0 bus 0 target 0 lun 0 Apr > 7 15:33:02 botelhor kernel: da0: Removable Direct > Access SCSI-0 device > Apr 7 15:33:02 botelhor kernel: da0: 1.000MB/s transfers > Apr 7 15:33:02 botelhor kernel: da0: 982MB (2012160 512 byte sectors: > 64H 32S/T 982C) > Apr 7 15:33:02 botelhor kernel: da1 at umass-sim0 bus 0 target 0 lun 1 > Apr 7 15:33:02 botelhor kernel: da1: Removable Direct > Access SCSI-0 device > Apr 7 15:33:02 botelhor kernel: da1: 1.000MB/s transfers > Apr 7 15:33:02 botelhor kernel: da1: 1MB (3668 512 byte sectors: 64H 32S/T > 1C) Apr 7 15:33:02 botelhor kernel: GEOM: da0: partition 1 does not start > on a track boundary. > Apr 7 15:33:02 botelhor kernel: GEOM: da0: partition 1 does not end > on a track boundary. > Apr 7 15:33:04 botelhor kernel: umass0: at uhub0, port 2, addr 2 > (disconnected) Apr 7 15:33:04 botelhor kernel: (da1:umass-sim0:0:0:1): > Synchronize cache failed, status == 0x3f, scsi status == 0x0 > Apr 7 15:33:04 botelhor kernel: (da0:umass-sim0:0:0:0): lost device > Apr 7 15:33:04 botelhor kernel: (da0:umass-sim0:0:0:0): removing device > entry Apr 7 15:33:04 botelhor kernel: (da1:umass-sim0:0:0:1): lost device > Apr 7 15:33:04 botelhor kernel: (da1:umass-sim0:0:0:1): removing device > entry Apr 7 15:33:04 botelhor kernel: ugen0.2: at usbus0 > (disconnected) > > Using 8.0-CURRENT r190550 > > I've tried on all usb ports, and have the same. Any idea? Your device probably needs the no synchronize cache quirk. See quirk table in /sys/dev/usb/storage/umass.c . --HPS From sean.bruno at dsl-only.net Tue Apr 7 23:18:06 2009 From: sean.bruno at dsl-only.net (Sean Bruno) Date: Tue Apr 7 23:18:13 2009 Subject: PPC Macbook + Firewire Message-ID: <1239169884.2625.4.camel@localhost.localdomain> If anyone has the ability to test their PPC Macbook with a Firewire device(external hard disk eg), I'd like to know the results. Please post dmesg output upon connecting the device if you can. Sean From marcus at FreeBSD.org Tue Apr 7 23:27:47 2009 From: marcus at FreeBSD.org (Joe Marcus Clarke) Date: Tue Apr 7 23:27:58 2009 Subject: Hal and KDM breakage (was Re: KDE4 and input events stalled) In-Reply-To: <49DC405B.7090208@freebsd.org> References: <934e1d760904061455o4736d643o1d07e3292192d94c@mail.gmail.com> <1239078081.1908.41.camel@balrog.2hip.net> <49DAE987.7090802@freebsd.org> <1239086408.35025.59.camel@shumai.marcuscom.com> <20090407185915.GY31409@albert.catwhisker.org> <49DBA371.3080804@freebsd.org> <92cd2ff70904071637h362da63ua13c1f8eca6fc616@mail.gmail.com> <1239147806.98664.12.camel@shumai.marcuscom.com> <92cd2ff70904071653r4bf3b381lf5de220b2e280c0c@mail.gmail.com> <1239150469.98664.18.camel@shumai.marcuscom.com> <49DC405B.7090208@freebsd.org> Message-ID: <1239172068.98664.35.camel@shumai.marcuscom.com> On Tue, 2009-04-07 at 23:12 -0700, Tim Kientzle wrote: > >>> I'm still curious whether it's feasible to just not monitor the vtys. > >> Sure, you can try it. Especially if you're not using GNOME, this might > >> be fine. Just remove the hacks from hald's rc.d script. > > I think I finally understand the issue here. Basically, > there seem to be two options: > > Option 1: Comment out this line from /usr/local/etc/rc.d/hald > #start_cmd="hald_start" > > After this change, the rc.d/hald script will start hald > immediately, so that hald will be running before /etc/ttys > is processed. > > This allows KDM/xdm/gdm to be started either from /etc/ttys > or from a very simple rc.d script (in particular, the 'lshal' > and 'getty' checks are not necessary in this case). > > The risk with this approach is that hald on 7-STABLE and > earlier may be unable to detect whether the user is local or > using a remote X terminal, and hence the auto-mount features > of KDE and Gnome may not function properly. On FreeBSD-CURRENT, > this should be fine and everything should work properly. > > Option 2: Use the current hald script as-is. > > With this, the rc.d/hald script sets up a background process > that will start hald only after /etc/ttys has been processed. > > As a result, KDM cannot be started in the traditional fashion > from /etc/ttys because KDM cannot be started before hald. > (Although Robert claims this should work...) > > In this case, KDM can only be started from an rc.d script, > and that rc.d script needs to use some variant of the > "lshal" hack to ensure that KDM won't start before hald. > > The advantage of this approach is that auto-mount should > function correctly in KDE and Gnome, even on 7-STABLE > and earlier. > > Joe: Did I get this right? This sounds right, but I have not validated the functionality of an immediate start of hald on -CURRENT. One problem we were seeing prior to bland's work, and prior to the delay was that the keyboard and mouse would lock up if CK was started before init spawned the ttys. So beyond making sure CK reports the correct active session, you would want to make sure X is usable at all. Joe > > Freddie Cash pointed out: > > Doesn't work, at least not in my quick-n-dirty testing, using the kdm4 > > script I just posted. If you remove the lshal checks, then the > > keyboard doesn't work once kdm starts. > > Freddie: If you remove the lshal checks from the kdm startup > script, then you have to also remove the hald_start > call from the hald startup script. Otherwise, kdm > will start before hald and bad things will happen > (keyboard/mouse failures at a minimum; I get a complete > black screen in this case). > > Tim > > -- Joe Marcus Clarke FreeBSD GNOME Team :: gnome@FreeBSD.org FreeNode / #freebsd-gnome http://www.FreeBSD.org/gnome -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: This is a digitally signed message part Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20090408/efd19565/attachment.pgp From ndenev at gmail.com Tue Apr 7 23:45:32 2009 From: ndenev at gmail.com (Niki Denev) Date: Tue Apr 7 23:45:40 2009 Subject: axe(4) (Belkin F5D5055) problems In-Reply-To: <20090408024901.GC37714@michelle.cdnetworks.co.kr> References: <75656435-49E2-457A-9CFE-8706CD44916E@gmail.com> <2e77fc10903280259s5a761cacs398b88649a2367fe@mail.gmail.com> <20090328102735.GE99923@michelle.cdnetworks.co.kr> <2e77fc10903280942u7c934aa4w80176680e9dff6d7@mail.gmail.com> <2e77fc10903281539h7b713711w116a90fd2bfadbcf@mail.gmail.com> <20090330021648.GE7076@michelle.cdnetworks.co.kr> <20090330024748.GF7076@michelle.cdnetworks.co.kr> <2e77fc10904071315q66d725bl76229d9bffd92f35@mail.gmail.com> <20090408024901.GC37714@michelle.cdnetworks.co.kr> Message-ID: <2e77fc10904072345o4d8215dcg561931ede528bcd6@mail.gmail.com> Hi Pyun, On Wed, Apr 8, 2009 at 5:49 AM, Pyun YongHyeon wrote: > On Tue, Apr 07, 2009 at 11:15:47PM +0300, Niki Denev wrote: > > [...] > > I've read the datasheet but I still don't understand why dsp > programming in truephy_reset is required. Anyway would you try > attached patch? And show me dmesg output generated by truephy(4). Here is the dmesg output with the latest patch. truephy0: PHY 1 on miibus0 truephy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto > >> I have temporarily replaced the belkin USB ethernet interface with an >> Apple USB ethernet, >> which also uses the axe(4) driver, but is only 100Mbit/s. >> As I suspected the negotiation problems do not exist with it, and >> everything seemed ok, until >> it started to stop working exactly like the previous adapter. >> Pings start to return "buffer space not available" and replugging or >> "usbconfig reset" the interface >> returns it to normal status. >> > > This sounds like different issue to me. Let's focus on the > truephy(4) until axe(4) get a valid link report. > Ok. With this patch the old problems still persist. >> It looks like that the packet loss that I've experienced with the >> Belkin gigabit adabter is one problem, >> and the interface stopping to work another. >> >> P.S.: I don't know if it could be my USB hardware, because the machine >> is a little bit "exotic", >> an HP ex470 MediaSmartServer, which was supposedly designed to run >> only embedded version of >> Windows and has a nasty SiS chipset in it (with the unsupported sis191 >> gigabit adapter) > > There had been a post for SiS191 driver. Check mailing list > archives. Unfortunately I don't have SiS191 controller so I > couldn't write a driver and commit the posted driver to tree. > Even though the controller is not for high performance servers it > would be enough to most desktop users. At least SiS controllers > does not seem to require special workarounds for silicon bugs which > are commonly found on RealTek/Marvell controllers. > Yes, I've tried to make this driver work for several days, I've found OpenSolaris driver and tried to get some stuff missing in the linux driver from it, but the best I got was to see some packets on the wire, but was never able to send anything. Also the SiS191 seems to have problems negotiating gigabit link, there are many posts about this when using Linux. > Alternatively you can use ndis(4) to use your SiS191 controller. I > don't know whether ndis(4) works for this controller though. > I've tried, but afair there were some functions in the driver that were not yet implemented in the ndis layer, so it didn't worked for me. Many thanks for your help! From weongyo.jeong at gmail.com Tue Apr 7 23:55:59 2009 From: weongyo.jeong at gmail.com (Weongyo Jeong) Date: Tue Apr 7 23:56:19 2009 Subject: [head tinderbox] failure on ia64/ia64 In-Reply-To: <20090408054623.B214B7302F@freebsd-current.sentex.ca> References: <20090408054623.B214B7302F@freebsd-current.sentex.ca> Message-ID: <20090408065552.GB77502@weongyo.cdnetworks.kr> On Wed, Apr 08, 2009 at 01:46:23AM -0400, FreeBSD Tinderbox wrote: > TB --- 2009-04-08 03:57:00 - tinderbox 2.6 running on freebsd-current.sentex.ca > TB --- 2009-04-08 03:57:00 - starting HEAD tinderbox run for ia64/ia64 > TB --- 2009-04-08 03:57:00 - cleaning the object tree > TB --- 2009-04-08 03:57:30 - cvsupping the source tree > TB --- 2009-04-08 03:57:30 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/ia64/ia64/supfile > TB --- 2009-04-08 03:57:38 - building world > TB --- 2009-04-08 03:57:38 - MAKEOBJDIRPREFIX=/obj > TB --- 2009-04-08 03:57:38 - PATH=/usr/bin:/usr/sbin:/bin:/sbin > TB --- 2009-04-08 03:57:38 - TARGET=ia64 > TB --- 2009-04-08 03:57:38 - TARGET_ARCH=ia64 > TB --- 2009-04-08 03:57:38 - TZ=UTC > TB --- 2009-04-08 03:57:38 - __MAKE_CONF=/dev/null > TB --- 2009-04-08 03:57:38 - cd /src > TB --- 2009-04-08 03:57:38 - /usr/bin/make -B buildworld > >>> World build started on Wed Apr 8 03:57:40 UTC 2009 > >>> Rebuilding the temporary build tree > >>> stage 1.1: legacy release compatibility shims > >>> stage 1.2: bootstrap tools > >>> stage 2.1: cleaning up the object tree > >>> stage 2.2: rebuilding the object tree > >>> stage 2.3: build tools > >>> stage 3: cross tools > >>> stage 4.1: building includes > >>> stage 4.2: building libraries > >>> stage 4.3: make dependencies > >>> stage 4.4: building everything > [...] > ===> usr.sbin/tzsetup (all) > cc -O2 -pipe -I/src/usr.sbin/tzsetup -std=gnu99 -c /src/usr.sbin/tzsetup/tzsetup.c > cc -O2 -pipe -I/src/usr.sbin/tzsetup -std=gnu99 -o tzsetup tzsetup.o -ldialog -lncurses > gzip -cn /src/usr.sbin/tzsetup/tzsetup.8 > tzsetup.8.gz > ===> usr.sbin/uathload (all) > cc -O2 -pipe -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wunused-parameter -Wno-uninitialized -Wno-pointer-sign -c /src/usr.sbin/uathload/uathload.c > ld -b binary -d -warn-common -r -d -o ar5523.o ar5523.bin > ld: failed to merge target specific data of file ar5523.bin > *** Error code 1 Should be fixed with r190836 now. Thanks. regards, Weongyo Jeong From ale at FreeBSD.org Wed Apr 8 00:21:13 2009 From: ale at FreeBSD.org (Alex Dupre) Date: Wed Apr 8 00:21:21 2009 Subject: xorg loops In-Reply-To: <1239129677.1947.14.camel@balrog.2hip.net> References: <49D8D03B.8090302@arcor.de> <3a142e750904050919l1388b559t9bbd751546e239e7@mail.gmail.com> <1238957462.1829.8.camel@balrog.2hip.net> <49D90363.6010602@arcor.de> <1238959921.1829.10.camel@balrog.2hip.net> <49DB573C.3020703@FreeBSD.org> <1239129677.1947.14.camel@balrog.2hip.net> Message-ID: <49DC5066.1010607@FreeBSD.org> Robert Noland ha scritto: > The root of the issue is that there are just too many ways to configure > input devices... Particularly mice. Marcus, jkim and I have tried to > make accommodations for all of the cases, but it gets rather tricky. > Users can have mice configured using psm0, ums0, (serial even), moused > and we have to be able to figure out if they are statically configured > in X or not, based on whether or not X has already opened one of the > file descriptors. Based on analyzing all of that, we decide whether or > not to advertise to X that it should attach the device. Thanks for your work and explanation. > If you are using moused, then hald *should* recognize that and > advertise /dev/sysmouse to X. Additional input devices, get added via > moused and hald knows that /dev/sysmouse is already opened by X, so it > shouldn't re-advertise the same port again. Actually I have a common USB mouse. xorg.conf contains the following section (autogenerated by "X -configure"): Section "InputDevice" Identifier "Mouse0" Driver "mouse" Option "Protocol" "auto" Option "Device" "/dev/sysmouse" Option "ZAxisMapping" "4 5 6 7" EndSection moused is not enabled in rc.conf, but the following process is started at boot by devd: /usr/sbin/moused -p /dev/ums0 -t auto -I /var/run/moused.ums0.pid I think this is one of the most common scenario. I use kdm from /etc/ttys, but it shouldn't be related, since I did tests with "X -config" from terminal console with the same results. Is it normal that hal-device doesn't show any mouse? -- Alex Dupre From kientzle at freebsd.org Wed Apr 8 00:23:19 2009 From: kientzle at freebsd.org (Tim Kientzle) Date: Wed Apr 8 00:23:26 2009 Subject: Hal and KDM breakage (was Re: KDE4 and input events stalled) In-Reply-To: <1239172068.98664.35.camel@shumai.marcuscom.com> References: <934e1d760904061455o4736d643o1d07e3292192d94c@mail.gmail.com> <1239078081.1908.41.camel@balrog.2hip.net> <49DAE987.7090802@freebsd.org> <1239086408.35025.59.camel@shumai.marcuscom.com> <20090407185915.GY31409@albert.catwhisker.org> <49DBA371.3080804@freebsd.org> <92cd2ff70904071637h362da63ua13c1f8eca6fc616@mail.gmail.com> <1239147806.98664.12.camel@shumai.marcuscom.com> <92cd2ff70904071653r4bf3b381lf5de220b2e280c0c@mail.gmail.com> <1239150469.98664.18.camel@shumai.marcuscom.com> <49DC405B.7090208@freebsd.org> <1239172068.98664.35.camel@shumai.marcuscom.com> Message-ID: <49DC50E3.8080600@freebsd.org> Joe Marcus Clarke wrote: > On Tue, 2009-04-07 at 23:12 -0700, Tim Kientzle wrote: >> >> Option 1: Comment out this line from /usr/local/etc/rc.d/hald >> #start_cmd="hald_start" > > This sounds right, but I have not validated the functionality of an > immediate start of hald on -CURRENT. One problem we were seeing prior > to bland's work, and prior to the delay was that the keyboard and mouse > would lock up if CK was started before init spawned the ttys. So beyond > making sure CK reports the correct active session, you would want to > make sure X is usable at all. I'm using an immediate hald startup right now with the traditional KDM entry in /etc/ttys and everything seems just spiffy. In particular, keyboard and mouse are quite happy. (My only problem right now are some X shutdown issues which I believe to be unrelated.) I'm not sure how to check "CK reports the correct active session", though. Pointers? Tim From marcus at FreeBSD.org Wed Apr 8 00:26:07 2009 From: marcus at FreeBSD.org (Joe Marcus Clarke) Date: Wed Apr 8 00:26:14 2009 Subject: Hal and KDM breakage (was Re: KDE4 and input events stalled) In-Reply-To: <49DC50E3.8080600@freebsd.org> References: <934e1d760904061455o4736d643o1d07e3292192d94c@mail.gmail.com> <1239078081.1908.41.camel@balrog.2hip.net> <49DAE987.7090802@freebsd.org> <1239086408.35025.59.camel@shumai.marcuscom.com> <20090407185915.GY31409@albert.catwhisker.org> <49DBA371.3080804@freebsd.org> <92cd2ff70904071637h362da63ua13c1f8eca6fc616@mail.gmail.com> <1239147806.98664.12.camel@shumai.marcuscom.com> <92cd2ff70904071653r4bf3b381lf5de220b2e280c0c@mail.gmail.com> <1239150469.98664.18.camel@shumai.marcuscom.com> <49DC405B.7090208@freebsd.org> <1239172068.98664.35.camel@shumai.marcuscom.com> <49DC50E3.8080600@freebsd.org> Message-ID: <1239175570.98664.47.camel@shumai.marcuscom.com> On Wed, 2009-04-08 at 00:23 -0700, Tim Kientzle wrote: > Joe Marcus Clarke wrote: > > On Tue, 2009-04-07 at 23:12 -0700, Tim Kientzle wrote: > >> > >> Option 1: Comment out this line from /usr/local/etc/rc.d/hald > >> #start_cmd="hald_start" > > > > This sounds right, but I have not validated the functionality of an > > immediate start of hald on -CURRENT. One problem we were seeing prior > > to bland's work, and prior to the delay was that the keyboard and mouse > > would lock up if CK was started before init spawned the ttys. So beyond > > making sure CK reports the correct active session, you would want to > > make sure X is usable at all. > > I'm using an immediate hald startup right now with > the traditional KDM entry in /etc/ttys and everything > seems just spiffy. In particular, keyboard and mouse > are quite happy. (My only problem right now are some > X shutdown issues which I believe to be unrelated.) > > I'm not sure how to check "CK reports the correct > active session", though. Pointers? I don't believe KDE is CK-aware, so tests would be meaningless. The command is ck-list-sessions, though. If working, the current session details should show up as being ACTIVE. Joe -- Joe Marcus Clarke FreeBSD GNOME Team :: gnome@FreeBSD.org FreeNode / #freebsd-gnome http://www.FreeBSD.org/gnome -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: This is a digitally signed message part Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20090408/ec681525/attachment.pgp From rnoland at FreeBSD.org Wed Apr 8 00:36:10 2009 From: rnoland at FreeBSD.org (Robert Noland) Date: Wed Apr 8 00:36:18 2009 Subject: xorg loops In-Reply-To: <49DC5066.1010607@FreeBSD.org> References: <49D8D03B.8090302@arcor.de> <3a142e750904050919l1388b559t9bbd751546e239e7@mail.gmail.com> <1238957462.1829.8.camel@balrog.2hip.net> <49D90363.6010602@arcor.de> <1238959921.1829.10.camel@balrog.2hip.net> <49DB573C.3020703@FreeBSD.org> <1239129677.1947.14.camel@balrog.2hip.net> <49DC5066.1010607@FreeBSD.org> Message-ID: <1239176118.1954.11.camel@balrog.2hip.net> On Wed, 2009-04-08 at 09:21 +0200, Alex Dupre wrote: > Robert Noland ha scritto: > > The root of the issue is that there are just too many ways to configure > > input devices... Particularly mice. Marcus, jkim and I have tried to > > make accommodations for all of the cases, but it gets rather tricky. > > Users can have mice configured using psm0, ums0, (serial even), moused > > and we have to be able to figure out if they are statically configured > > in X or not, based on whether or not X has already opened one of the > > file descriptors. Based on analyzing all of that, we decide whether or > > not to advertise to X that it should attach the device. > > Thanks for your work and explanation. > > > If you are using moused, then hald *should* recognize that and > > advertise /dev/sysmouse to X. Additional input devices, get added via > > moused and hald knows that /dev/sysmouse is already opened by X, so it > > shouldn't re-advertise the same port again. > > Actually I have a common USB mouse. xorg.conf contains the following > section (autogenerated by "X -configure"): > > Section "InputDevice" > Identifier "Mouse0" > Driver "mouse" > Option "Protocol" "auto" > Option "Device" "/dev/sysmouse" > Option "ZAxisMapping" "4 5 6 7" > EndSection > > moused is not enabled in rc.conf, but the following process is started > at boot by devd: > > /usr/sbin/moused -p /dev/ums0 -t auto -I /var/run/moused.ums0.pid Right, all usb mice start moused unless moused_nondefault_enable is set to no in rc.conf. This configuration should be fine, in fact if your using hal, the above is totally ignored. I generally use gnome, unless I'm working on drm drivers that are either broken or don't yet support enough whiz bang to run gnome. In those cases, I'm just using startx to get twm going for basic testing. Your configuration should work fine in all of those cases. kdm and xdm when started from /etc/ttys are still a problem apparently, at least some of the time. > I think this is one of the most common scenario. I use kdm from > /etc/ttys, but it shouldn't be related, since I did tests with "X > -config" from terminal console with the same results. > Is it normal that hal-device doesn't show any mouse? So, I think your issue is probably related to the other thread. "Re: Hal and KDM breakage". robert. -- Robert Noland FreeBSD -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 196 bytes Desc: This is a digitally signed message part Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20090408/408edb0c/attachment.pgp From onemda at gmail.com Wed Apr 8 01:13:06 2009 From: onemda at gmail.com (Paul B. Mahol) Date: Wed Apr 8 01:13:13 2009 Subject: axe(4) (Belkin F5D5055) problems In-Reply-To: <2e77fc10904072345o4d8215dcg561931ede528bcd6@mail.gmail.com> References: <75656435-49E2-457A-9CFE-8706CD44916E@gmail.com> <20090328102735.GE99923@michelle.cdnetworks.co.kr> <2e77fc10903280942u7c934aa4w80176680e9dff6d7@mail.gmail.com> <2e77fc10903281539h7b713711w116a90fd2bfadbcf@mail.gmail.com> <20090330021648.GE7076@michelle.cdnetworks.co.kr> <20090330024748.GF7076@michelle.cdnetworks.co.kr> <2e77fc10904071315q66d725bl76229d9bffd92f35@mail.gmail.com> <20090408024901.GC37714@michelle.cdnetworks.co.kr> <2e77fc10904072345o4d8215dcg561931ede528bcd6@mail.gmail.com> Message-ID: <3a142e750904080113s484b6c7emb2ad0caf85f320b4@mail.gmail.com> On 4/8/09, Niki Denev wrote: > Hi Pyun, > > On Wed, Apr 8, 2009 at 5:49 AM, Pyun YongHyeon wrote: >> On Tue, Apr 07, 2009 at 11:15:47PM +0300, Niki Denev wrote: >> >> [...] >> >> I've read the datasheet but I still don't understand why dsp >> programming in truephy_reset is required. Anyway would you try >> attached patch? And show me dmesg output generated by truephy(4). > > Here is the dmesg output with the latest patch. > > truephy0: PHY 1 on miibus0 > truephy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, > 1000baseT-FDX, auto > > >> >>> I have temporarily replaced the belkin USB ethernet interface with an >>> Apple USB ethernet, >>> which also uses the axe(4) driver, but is only 100Mbit/s. >>> As I suspected the negotiation problems do not exist with it, and >>> everything seemed ok, until >>> it started to stop working exactly like the previous adapter. >>> Pings start to return "buffer space not available" and replugging or >>> "usbconfig reset" the interface >>> returns it to normal status. >>> >> >> This sounds like different issue to me. Let's focus on the >> truephy(4) until axe(4) get a valid link report. >> > > Ok. > With this patch the old problems still persist. > >>> It looks like that the packet loss that I've experienced with the >>> Belkin gigabit adabter is one problem, >>> and the interface stopping to work another. >>> >>> P.S.: I don't know if it could be my USB hardware, because the machine >>> is a little bit "exotic", >>> an HP ex470 MediaSmartServer, which was supposedly designed to run >>> only embedded version of >>> Windows and has a nasty SiS chipset in it (with the unsupported sis191 >>> gigabit adapter) >> >> There had been a post for SiS191 driver. Check mailing list >> archives. Unfortunately I don't have SiS191 controller so I >> couldn't write a driver and commit the posted driver to tree. >> Even though the controller is not for high performance servers it >> would be enough to most desktop users. At least SiS controllers >> does not seem to require special workarounds for silicon bugs which >> are commonly found on RealTek/Marvell controllers. >> > > Yes, I've tried to make this driver work for several days, I've found > OpenSolaris driver and tried to get some stuff missing in the linux > driver from it, > but the best I got was to see some packets on the wire, but was never > able to send anything. > Also the SiS191 seems to have problems negotiating gigabit link, there > are many posts about this > when using Linux. > >> Alternatively you can use ndis(4) to use your SiS191 controller. I >> don't know whether ndis(4) works for this controller though. >> > > I've tried, but afair there were some functions in the driver that > were not yet implemented > in the ndis layer, so it didn't worked for me. Please tell me what functions? Or provide link to driver you used. -- Paul From pluknet at gmail.com Wed Apr 8 01:15:23 2009 From: pluknet at gmail.com (pluknet) Date: Wed Apr 8 01:15:30 2009 Subject: someone is eating massive menory In-Reply-To: References: Message-ID: 2009/4/8 Randy Bush : > amd64, 4g ram, geom mirror and zfs > > another amd64 4g system is not crashing but is being very sloggish for > 3-5 minutes. > > work0.psg.com:/root# uname -a > FreeBSD work0.psg.com 8.0-CURRENT FreeBSD 8.0-CURRENT #22: Mon Apr 6 01:41:51 UTC 2009 > root@work0.psg.com:/usr/obj/usr/src/sys/WORK0 amd64 > > when midnight crons run, it's death. this is from serial console > > swap_pager_getswapspace(9): failed > swap_pager_getswapspace(3): failed > swap_pager_getswapspace(3): failed > swap_pager_getswapspace(3): failed > swap_pager_getswapspace(3): failed > swap_pager_getswapspace(3): failed > swap_pager_getswapspace(3): failed > swap_pager_getswapspace(3): failed > swap_pager_getswapspace(3): failed > swap_pager_getswapspace(3): failed > swap_pager_getswapspace(3): failed > swap_pager_getswapspace(3): failed > swap_pager_getswapspace(16): failed > swap_pager_getswapspace(3): failed > swap_pager_getswapspace(16): failed > swap_pager_getswapspace(3): failed > swap_pager_getswapspace(3): failed > swap_pager_getswapspace(3): failed > swap_pager_getswapspace(3): failed > If your system survived you could grep /var/log/messages for processes killed by kernel. That'd help you to find the guilty procs eating all memory. Look at vm_pageout.c. -- wbr, pluknet From mav at FreeBSD.org Wed Apr 8 01:32:48 2009 From: mav at FreeBSD.org (Alexander Motin) Date: Wed Apr 8 01:32:56 2009 Subject: AMD 780G chipset major issues 1/3 (ata, ataati) In-Reply-To: <83e5fb980904071402k600cbc09hcde8994cb5465f52@mail.gmail.com> References: <1239063789.00097213.1239052203@10.7.7.3> <49DBAEB5.7010500@FreeBSD.org> <20090407200257.GB19850@home.opsec.eu> <49DBB3C0.9010800@FreeBSD.org> <83e5fb980904071402k600cbc09hcde8994cb5465f52@mail.gmail.com> Message-ID: <49DC6129.4070107@FreeBSD.org> Diego Depaoli wrote: > On Tue, Apr 7, 2009 at 10:12 PM, Alexander Motin wrote: >> Kurt Jaeger wrote: >>>>> 2 -> with ataati loaded as module >>> [...] >>>>> ad4: 305245MB at ata2-master SATA300 >>>>> ad6: 305245MB at ata3-master SATA300 >>>>> >>>>> my sata disks are right, but ata1 and acd0 vanished >>>> Is your DVD drive SATA or PATA? > It's PATA According to what I have found on the net, this chipset has 6 SATA and one PATA ports. When you are disabling ataati driver ATA controllers work in legacy ATA emulation mode, which emulates 8 possible devices access via 4 legacy PATA channels. ataati driver loading switches first controller into native AHCI mode, which for some reason gives you only four ports, not six, may be last two are still under the legacy emulation. And disables second port on PATA controller, which actually should not be there, but looks like present, according to common driver operation. I would say that there is some misconfiguration between BIOS ATA emulation settings and ataati driver expectations. Is there any switches like Native/AHCI/RAID/Legacy in your BIOS settings? Have you tried to play with them? You can try to comment out 'ctlr->channels = 1;' line in your ata-ati.c file to allow second channel of the second controller to be attached. -- Alexander Motin From mav at FreeBSD.org Wed Apr 8 01:38:14 2009 From: mav at FreeBSD.org (Alexander Motin) Date: Wed Apr 8 01:38:21 2009 Subject: AMD 780G chipset major issues 2/3 (snd_hda) In-Reply-To: <1239142508.1947.26.camel@balrog.2hip.net> References: <1239063789.00097214.1239052203@10.7.7.3> <1239063790.00097218.1239052203@10.7.7.3> <1239063792.00097228.1239052802@10.7.7.3> <49DBBE59.2080801@mavhome.dp.ua> <1239142508.1947.26.camel@balrog.2hip.net> Message-ID: <49DC6273.1040907@FreeBSD.org> Robert Noland wrote: > On Tue, 2009-04-07 at 23:58 +0300, Alexander Motin wrote: >> Diego Depaoli wrote: >>> On Mon, Apr 6, 2009 at 11:06 PM, Paul B. Mahol wrote: >>>> Because pcm0 switched position with pcm1 :-) >>> Already noticed. >>> Do you know why? >> It is really interesting question, but probably to the PCI guys. > > I think it is due to bus enumeration... the first one found (i.e. lower > bus id) becomes pcm0. If I plug in the radeon HD 3850 which has hdmi > audio, it ends up being pcm0, instead of my rear ports. I also have a > seperate codec for front ports, which is a bit of a pain, but... I understand this, I am surprised that attach orders on boot and later are different: on boot: hdac0: mem 0xfeae8000-0xfeaebfff irq 19 at device 5.1 on pci1 hdac1: mem 0xfe8f4000-0xfe8f7fff irq 16 at device 20.2 on pci0 later: hdac0: mem 0xfe8f4000-0xfe8f7fff irq 16 at device 20.2 on pci0 hdac1: mem 0xfeae8000-0xfeaebfff irq 19 at device 5.1 on pci1 Any ideas? -- Alexander Motin From rnoland at FreeBSD.org Wed Apr 8 01:45:14 2009 From: rnoland at FreeBSD.org (Robert Noland) Date: Wed Apr 8 01:45:21 2009 Subject: AMD 780G chipset major issues 2/3 (snd_hda) In-Reply-To: <49DC6273.1040907@FreeBSD.org> References: <1239063789.00097214.1239052203@10.7.7.3> <1239063790.00097218.1239052203@10.7.7.3> <1239063792.00097228.1239052802@10.7.7.3> <49DBBE59.2080801@mavhome.dp.ua> <1239142508.1947.26.camel@balrog.2hip.net> <49DC6273.1040907@FreeBSD.org> Message-ID: <1239180261.1954.15.camel@balrog.2hip.net> On Wed, 2009-04-08 at 11:38 +0300, Alexander Motin wrote: > Robert Noland wrote: > > On Tue, 2009-04-07 at 23:58 +0300, Alexander Motin wrote: > >> Diego Depaoli wrote: > >>> On Mon, Apr 6, 2009 at 11:06 PM, Paul B. Mahol wrote: > >>>> Because pcm0 switched position with pcm1 :-) > >>> Already noticed. > >>> Do you know why? > >> It is really interesting question, but probably to the PCI guys. > > > > I think it is due to bus enumeration... the first one found (i.e. lower > > bus id) becomes pcm0. If I plug in the radeon HD 3850 which has hdmi > > audio, it ends up being pcm0, instead of my rear ports. I also have a > > seperate codec for front ports, which is a bit of a pain, but... > > I understand this, I am surprised that attach orders on boot and later > are different: > > on boot: > hdac0: mem > 0xfeae8000-0xfeaebfff irq 19 at device 5.1 on pci1 > hdac1: mem > 0xfe8f4000-0xfe8f7fff irq 16 at device 20.2 on pci0 > > later: > hdac0: mem > 0xfe8f4000-0xfe8f7fff irq 16 at device 20.2 on pci0 > hdac1: mem > 0xfeae8000-0xfeaebfff irq 19 at device 5.1 on pci1 > > Any ideas? jhb is really the guru here... but my guess is that the first is the initial probe. If you notice the second sequence is in bus order, which I'm guessing is the order that they were attached in. robert. -- Robert Noland FreeBSD -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 196 bytes Desc: This is a digitally signed message part Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20090408/9633e31a/attachment.pgp From randy at psg.com Wed Apr 8 01:53:05 2009 From: randy at psg.com (Randy Bush) Date: Wed Apr 8 01:53:15 2009 Subject: someone is eating massive menory In-Reply-To: References: Message-ID: >> swap_pager_getswapspace(9): failed >> swap_pager_getswapspace(3): failed >> swap_pager_getswapspace(3): failed >> swap_pager_getswapspace(3): failed >> swap_pager_getswapspace(3): failed >> swap_pager_getswapspace(3): failed >> swap_pager_getswapspace(3): failed >> swap_pager_getswapspace(3): failed >> swap_pager_getswapspace(3): failed >> swap_pager_getswapspace(3): failed >> swap_pager_getswapspace(3): failed >> swap_pager_getswapspace(3): failed >> swap_pager_getswapspace(16): failed >> swap_pager_getswapspace(3): failed >> swap_pager_getswapspace(16): failed >> swap_pager_getswapspace(3): failed >> swap_pager_getswapspace(3): failed >> swap_pager_getswapspace(3): failed >> swap_pager_getswapspace(3): failed > If your system survived i gave it 15 minutes and then whacked the remote power bar. and /var/log/messages has no clues i have cut in half to kern.maxdsiz=16777216 in /boot/loader.conf.local to try and catch it earlier. perhaps i should make it even smaller? randy From horst at sxemacs.org Wed Apr 8 01:59:28 2009 From: horst at sxemacs.org (Horst =?ISO-8859-1?Q?G=FCnther?= Burkhardt III) Date: Wed Apr 8 01:59:35 2009 Subject: PPC Macbook + Firewire In-Reply-To: <1239169884.2625.4.camel@localhost.localdomain> References: <1239169884.2625.4.camel@localhost.localdomain> Message-ID: <1239181170.2433.1935.camel@horst-tla> On Tue, 2009-04-07 at 22:51 -0700, Sean Bruno wrote: > If anyone has the ability to test their PPC Macbook with a Firewire > device(external hard disk eg), I'd like to know the results. > > Please post dmesg output upon connecting the device if you can. > > Sean Hi Sean. First, I'm not aware of _any_ MacBook being PPC based, the PPC laptops were the iBook and PowerBook, perhaps they are what you refer to? Second, I've CC'd this to freebsd-ppc, where you are more likely to find help :) -- Horst -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20090408/a31ab286/attachment.pgp From jrh29 at alumni.cwru.edu Wed Apr 8 04:01:44 2009 From: jrh29 at alumni.cwru.edu (Justin Hibbits) Date: Wed Apr 8 04:01:50 2009 Subject: PPC Macbook + Firewire In-Reply-To: <1239181170.2433.1935.camel@horst-tla> References: <1239169884.2625.4.camel@localhost.localdomain> <1239181170.2433.1935.camel@horst-tla> Message-ID: <20090408110223.GB46038@narn.knownspace> On Wed, Apr 08, 2009 at 06:59:30PM +1000, Horst G?nther Burkhardt III wrote: > On Tue, 2009-04-07 at 22:51 -0700, Sean Bruno wrote: > > If anyone has the ability to test their PPC Macbook with a Firewire > > device(external hard disk eg), I'd like to know the results. > > > > Please post dmesg output upon connecting the device if you can. > > > > Sean > > Hi Sean. > > First, I'm not aware of _any_ MacBook being PPC based, the PPC laptops > were the iBook and PowerBook, perhaps they are what you refer to? > > Second, I've CC'd this to freebsd-ppc, where you are more likely to find > help :) > > -- Horst I'm pretty sure he meant PowerBook or iBook (used to be referred to as MacBooks until the MacBook came out). - Justin From M.S.Powell at salford.ac.uk Wed Apr 8 04:06:11 2009 From: M.S.Powell at salford.ac.uk (Mark Powell) Date: Wed Apr 8 04:06:18 2009 Subject: AMD 780G chipset major issues 3/3 (btx) In-Reply-To: <1239132158.1947.21.camel@balrog.2hip.net> References: <83e5fb980904061402q73940f8at4ec4b8f821354320@mail.gmail.com> <200904062321.47691.thierry.herbelot@free.fr> <20090407095804.G8569@rust.salford.ac.uk> <1239132158.1947.21.camel@balrog.2hip.net> Message-ID: <20090408120531.F8569@rust.salford.ac.uk> On Tue, 7 Apr 2009, Robert Noland wrote: > I can't really speak for the other components, but afaik, all of the > radeon IGPs should be working ok. I think it is an 780G that AMD is > planning to send me once it gets approved as well... Do you know of any 780G MBs with 6xSATA, or preferably 8xSATA? Cheers. -- Mark Powell - UNIX System Administrator - The University of Salford Information & Learning Services, Clifford Whitworth Building, Salford University, Manchester, M5 4WT, UK. Tel: +44 161 295 6843 Fax: +44 161 295 5888 www.pgp.com for PGP key From trebestie at gmail.com Wed Apr 8 04:14:08 2009 From: trebestie at gmail.com (Diego Depaoli) Date: Wed Apr 8 04:14:15 2009 Subject: AMD 780G chipset major issues 1/3 (ata, ataati) In-Reply-To: <49DC6129.4070107@FreeBSD.org> References: <1239063789.00097213.1239052203@10.7.7.3> <49DBAEB5.7010500@FreeBSD.org> <20090407200257.GB19850@home.opsec.eu> <49DBB3C0.9010800@FreeBSD.org> <83e5fb980904071402k600cbc09hcde8994cb5465f52@mail.gmail.com> <49DC6129.4070107@FreeBSD.org> Message-ID: <83e5fb980904080414v41735e80p42b11ff3f3025f13@mail.gmail.com> On Wed, Apr 8, 2009 at 10:32 AM, Alexander Motin wrote: > > I would say that there is some misconfiguration between BIOS ATA > emulation settings and ataati driver expectations. Is there any switches > like Native/AHCI/RAID/Legacy in your BIOS settings? Have you tried to > play with them? as reported in other post bios has 3 options ide, ahci, raid With ahci FreeBSD doesn't boot at all (btx halted) I didn't try raid. -- Diego Depaoli From trebestie at gmail.com Wed Apr 8 04:24:27 2009 From: trebestie at gmail.com (Diego Depaoli) Date: Wed Apr 8 04:24:34 2009 Subject: AMD 780G chipset major issues 1/3 (ata, ataati) In-Reply-To: <200904071757.04734.jkim@FreeBSD.org> References: <1239063789.00097213.1239052203@10.7.7.3> <49DBB3C0.9010800@FreeBSD.org> <83e5fb980904071402k600cbc09hcde8994cb5465f52@mail.gmail.com> <200904071757.04734.jkim@FreeBSD.org> Message-ID: <83e5fb980904080424w1dda7fb3tf1c26ac72752352f@mail.gmail.com> On Tue, Apr 7, 2009 at 11:57 PM, Jung-uk Kim wrote: > I have a similar board and it seems to share the broken ACPI DSDT. At this point I consider acpi's issues very minor issues. The hard reality is than I can't install and run FreeBSD out of the box on such board bought in the last five years (and I do not ever buy products just released on the market). -- Diego Depaoli From andreast-list at fgznet.ch Wed Apr 8 04:42:08 2009 From: andreast-list at fgznet.ch (Andreas Tobler) Date: Wed Apr 8 04:42:19 2009 Subject: PPC Macbook + Firewire In-Reply-To: <1239181170.2433.1935.camel@horst-tla> References: <1239169884.2625.4.camel@localhost.localdomain> <1239181170.2433.1935.camel@horst-tla> Message-ID: <49DC8D7F.5070403@fgznet.ch> Horst G?nther Burkhardt III wrote: > On Tue, 2009-04-07 at 22:51 -0700, Sean Bruno wrote: >> If anyone has the ability to test their PPC Macbook with a Firewire >> device(external hard disk eg), I'd like to know the results. >> >> Please post dmesg output upon connecting the device if you can. >> >> Sean > > Hi Sean. > > First, I'm not aware of _any_ MacBook being PPC based, the PPC laptops > were the iBook and PowerBook, perhaps they are what you refer to? In case you meant the PowerBook (PPC based), attached a dmesg. Andreas -------------- next part -------------- Copyright (c) 1992-2009 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 is a registered trademark of The FreeBSD Foundation. FreeBSD 8.0-CURRENT #3: Sat Feb 21 14:30:20 CET 2009 andreast@wolfram.andreas.nets:/usr/obj/export/devel/fbsd/src/sys/ANDREAST cpu0: Motorola PowerPC 7447A revision 1.1, 1504.63 MHz cpu0: L1 I-cache enabled, L1 D-cache enabled cpu0: 512KB L2 cache cpu0: HID0 8450c0bc cpu0: HID1 8000fc80 real memory = 1063022592 (1013 MB) avail memory = 1026883584 (979 MB) nexus0: powermac_nvram0: on nexus0 powermac_nvram0: bank0 generation 432, bank1 generation 431 unin0: on nexus0 unin0: Version 210 pcib0: on nexus0 pci0: on pcib0 vgapci0: port 0x400-0x4ff mem 0xb8000000-0xbfffffff,0xb0000000-0xb000ffff irq 48 at device 16.0 on pci0 pcib1: on nexus0 pci1: on pcib1 macio0: mem 0x80000000-0x8007ffff at device 23.0 on pci1 openpic0: mem 0x40000-0x7ffff on macio0 macgpio0: mem 0x50-0x7f on macio0 pmuextint0: extint-gpio 1 irq 47 on macgpio0 scc0: mem 0x13000-0x13fff,0x8400-0x84ff,0x8500-0x85ff,0x8600-0x86ff,0x8700-0x87ff irq 22,5,6,23,7,8 on macio0 scc0: [FILTER] scc0: [FILTER] uart0: on scc0 uart0: [FILTER] uart1: on scc0 uart1: [FILTER] pmu0: mem 0x16000-0x17fff irq 25 on macio0 pmu0: [ITHREAD] adb0: on pmu0 iichb0: mem 0x18000-0x18fff irq 26 on macio0 iichb0: [ITHREAD] iicbus0: on iichb0 iicbus0: at addr 0x1c0 iicbus0: at addr 0x6a ata0: mem 0x20000-0x20fff,0x8800-0x88ff irq 24,12 on macio0 ata0: [ITHREAD] pci1: at device 18.0 (no driver attached) pci1: at device 19.0 (no driver attached) ohci0: mem 0xa0003000-0xa0003fff irq 29 at device 26.0 on pci1 ohci0: [ITHREAD] usbus0: on ohci0 ohci1: mem 0xa0002000-0xa0002fff irq 63 at device 27.0 on pci1 ohci1: [ITHREAD] usbus1: on ohci1 ohci2: mem 0xa0001000-0xa0001fff irq 63 at device 27.1 on pci1 ohci2: [ITHREAD] usbus2: on ohci2 ehci0: mem 0xa0000000-0xa00000ff irq 63 at device 27.2 on pci1 ehci0: [ITHREAD] usbus3: EHCI version 1.0 usbus3: on ehci0 ohci3: irq 0 at device 24.0 on pci1 ohci3: [ITHREAD] usbus4: on ohci3 ohci4: irq 0 at device 25.0 on pci1 ohci4: [ITHREAD] usbus5: on ohci4 pcib2: on nexus0 pci2: on pcib2 ata1: mem 0xf5004000-0xf5007fff irq 39 at device 13.0 on pci2 ata1: [ITHREAD] fwohci0: mem 0xf5000000-0xf5000fff irq 40 at device 14.0 on pci2 fwohci0: [ITHREAD] fwohci0: OHCI version 1.10 (ROM=0) fwohci0: No. of Isochronous channels is 8. fwohci0: EUI64 00:0d:93:ff:fe:35:b3:80 fwohci0: invalid speed 7 (fixed to 3). fwohci0: Phy 1394a available S800, 3 ports. fwohci0: Link S800, max_rec 4096 bytes. firewire0: on fwohci0 fwe0: on firewire0 if_fwe0: Fake Ethernet address: 02:0d:93:35:b3:80 fwe0: Ethernet address: 02:0d:93:35:b3:80 sbp0: on firewire0 fwohci0: Initiate bus reset fwohci0: fwohci_intr_core: BUS reset fwohci0: fwohci_intr_core: node_id=0x00000001, SelfID Count=2, CYCLEMASTER mode gem0: mem 0xf5200000-0xf53fffff irq 41 at device 15.0 on pci2 miibus0: on gem0 e1000phy0: PHY 0 on miibus0 e1000phy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseTX-FDX, auto gem0: 10kB RX FIFO, 4kB TX FIFO gem0: Ethernet address: 00:0d:93:35:b3:80 gem0: [ITHREAD] sc0: on nexus0 sc0: Unknown <16 virtual consoles, flags=0x300> Timecounter "decrementer" frequency 18432000 Hz quality 0 Timecounters tick every 10.000 msec firewire0: 2 nodes, maxhop <= 1 cable IRM irm(1) (me) firewire0: bus manager 1 usbus0: 12Mbps Full Speed USB v1.0 usbus1: 12Mbps Full Speed USB v1.0 usbus2: 12Mbps Full Speed USB v1.0 ugen0.1: at usbus0 ushub0: on usbus0 ugen1.1: at usbus1 ushub1: on usbus1 ugen2.1: at usbus2 ushub2: on usbus2 usbus3: 480Mbps High Speed USB v2.0 usbus4: 12Mbps Full Speed USB v1.0 usbus5: 12Mbps Full Speed USB v1.0 ugen3.1: at usbus3 ushub3: on usbus3 ugen4.1: at usbus4 ushub4: on usbus4 ugen5.1: at usbus5 ushub5: on usbus5 firewire0: fw_explore_nodePre 1394a-2000 detected firewire0: fw_explore_node: fwdev->speed(S400) set lower than binfo->link_spd(S100) firewire0: New S400 device ID:0001d200005b017a sbp0: sbp_show_sdev_info: sbp0:0:0: ordered:1 type:0 EUI:0001d200005b017a node:0 speed:2 maxrec:0 sbp0: sbp_show_sdev_info: sbp0:0:0 'Oxford Semiconductor Ltd. ' 'OXFORD IDE Device LUN 0 ' '000138' ushub0: 2 ports with 2 removable, self powered acd0: DVDR at ata0-master WDMA2 ad0: 76319MB at ata1-master UDMA100 ushub2: 2 ports with 2 removable, self powered ushub1: 3 ports with 3 removable, self powered akbd0: at device 2 on adb0 ams0: at device 3 on adb0 ams0: 4-button 400-dpi Touchpad ugen0.2: at usbus0 ukbd0: on usbus0 ums0: on usbus0 ums0: 5 buttons and [XY] coordinates Symlink: ums0 -> usb0.2.1.16 ushub4: 2 ports with 2 removable, self powered ushub5: 2 ports with 2 removable, self powered ushub3: 5 ports with 5 removable, self powered da0 at sbp0 bus 0 target 0 lun 0 da0: Fixed Simplified Direct Access SCSI-4 device da0: 50.000MB/s transfers da0: 131071MB (268435455 512 byte sectors: 255H 63S/T 16709C) Trying to mount root from ufs:/dev/da0s5 gem0: link state changed to UP gem0: link state changed to DOWN gem0: link state changed to UP gem0: link state changed to DOWN gem0: link state changed to UP From rbgarga at gmail.com Wed Apr 8 05:25:41 2009 From: rbgarga at gmail.com (Renato Botelho) Date: Wed Apr 8 05:25:47 2009 Subject: new usb: mass storage error, Synchronize cache failed In-Reply-To: <200904080816.09996.hselasky@c2i.net> References: <747dc8f30904071139j32b55e2pf0fcd07a51c260a2@mail.gmail.com> <200904080816.09996.hselasky@c2i.net> Message-ID: <747dc8f30904080525p4e8dfe7fi15e6e758338467c8@mail.gmail.com> On Wed, Apr 8, 2009 at 3:16 AM, Hans Petter Selasky wrote: > On Tuesday 07 April 2009, Renato Botelho wrote: >> When I plug a gradiente cell phone on my USB I got this: >> >> Apr ?7 15:33:01 botelhor root: Unknown USB device: vendor 0x0e8d >> product 0x0002 bus uhub0 >> Apr ?7 15:33:01 botelhor kernel: ugen0.2: at usbus0 >> Apr ?7 15:33:01 botelhor kernel: umass0: on usbus0 >> Apr ?7 15:33:01 botelhor kernel: umass0: ?SCSI over Bulk-Only; quirks = >> 0x0000 Apr ?7 15:33:02 botelhor kernel: umass0:0:0:-1: Attached to scbus0 >> Apr ?7 15:33:02 botelhor kernel: da0 at umass-sim0 bus 0 target 0 lun 0 Apr >> ?7 15:33:02 botelhor kernel: da0: Removable Direct >> Access SCSI-0 device >> Apr ?7 15:33:02 botelhor kernel: da0: 1.000MB/s transfers >> Apr ?7 15:33:02 botelhor kernel: da0: 982MB (2012160 512 byte sectors: >> 64H 32S/T 982C) >> Apr ?7 15:33:02 botelhor kernel: da1 at umass-sim0 bus 0 target 0 lun 1 >> Apr ?7 15:33:02 botelhor kernel: da1: Removable Direct >> Access SCSI-0 device >> Apr ?7 15:33:02 botelhor kernel: da1: 1.000MB/s transfers >> Apr ?7 15:33:02 botelhor kernel: da1: 1MB (3668 512 byte sectors: 64H 32S/T >> 1C) Apr ?7 15:33:02 botelhor kernel: GEOM: da0: partition 1 does not start >> on a track boundary. >> Apr ?7 15:33:02 botelhor kernel: GEOM: da0: partition 1 does not end >> on a track boundary. >> Apr ?7 15:33:04 botelhor kernel: umass0: at uhub0, port 2, addr 2 >> (disconnected) Apr ?7 15:33:04 botelhor kernel: (da1:umass-sim0:0:0:1): >> Synchronize cache failed, status == 0x3f, scsi status == 0x0 >> Apr ?7 15:33:04 botelhor kernel: (da0:umass-sim0:0:0:0): lost device >> Apr ?7 15:33:04 botelhor kernel: (da0:umass-sim0:0:0:0): removing device >> entry Apr ?7 15:33:04 botelhor kernel: (da1:umass-sim0:0:0:1): lost device >> Apr ?7 15:33:04 botelhor kernel: (da1:umass-sim0:0:0:1): removing device >> entry Apr ?7 15:33:04 botelhor kernel: ugen0.2: at usbus0 >> (disconnected) >> >> Using 8.0-CURRENT r190550 >> >> I've tried on all usb ports, and have the same. Any idea? > > > Your device probably needs the no synchronize cache quirk. See quirk table > in /sys/dev/usb/storage/umass.c . Hans, I got it and can make tests here, but, i cannot find EZZE-E800GF or nothing related on usbdevs, I don't know where this description came from. Could you point me to the right place? Thanks -- Renato Botelho From hselasky at c2i.net Wed Apr 8 05:36:31 2009 From: hselasky at c2i.net (Hans Petter Selasky) Date: Wed Apr 8 05:36:38 2009 Subject: new usb: mass storage error, Synchronize cache failed In-Reply-To: <747dc8f30904080525p4e8dfe7fi15e6e758338467c8@mail.gmail.com> References: <747dc8f30904071139j32b55e2pf0fcd07a51c260a2@mail.gmail.com> <200904080816.09996.hselasky@c2i.net> <747dc8f30904080525p4e8dfe7fi15e6e758338467c8@mail.gmail.com> Message-ID: <200904081438.59388.hselasky@c2i.net> On Wednesday 08 April 2009, Renato Botelho wrote: > On Wed, Apr 8, 2009 at 3:16 AM, Hans Petter Selasky wrote: > > On Tuesday 07 April 2009, Renato Botelho wrote: > >> When I plug a gradiente cell phone on my USB I got this: > >> > >> Apr ?7 15:33:01 botelhor root: Unknown USB device: vendor 0x0e8d > >> product 0x0002 bus uhub0 > >> Apr ?7 15:33:01 botelhor kernel: ugen0.2: at usbus0 > >> Apr ?7 15:33:01 botelhor kernel: umass0: on usbus0 > >> Apr ?7 15:33:01 botelhor kernel: umass0: ?SCSI over Bulk-Only; quirks = > >> 0x0000 Apr ?7 15:33:02 botelhor kernel: umass0:0:0:-1: Attached to > >> scbus0 Apr ?7 15:33:02 botelhor kernel: da0 at umass-sim0 bus 0 target 0 > >> lun 0 Apr 7 15:33:02 botelhor kernel: da0: Removable Direct > >> Access SCSI-0 device > >> Apr ?7 15:33:02 botelhor kernel: da0: 1.000MB/s transfers > >> Apr ?7 15:33:02 botelhor kernel: da0: 982MB (2012160 512 byte sectors: > >> 64H 32S/T 982C) > >> Apr ?7 15:33:02 botelhor kernel: da1 at umass-sim0 bus 0 target 0 lun 1 > >> Apr ?7 15:33:02 botelhor kernel: da1: Removable Direct > >> Access SCSI-0 device > >> Apr ?7 15:33:02 botelhor kernel: da1: 1.000MB/s transfers > >> Apr ?7 15:33:02 botelhor kernel: da1: 1MB (3668 512 byte sectors: 64H > >> 32S/T 1C) Apr ?7 15:33:02 botelhor kernel: GEOM: da0: partition 1 does > >> not start on a track boundary. > >> Apr ?7 15:33:02 botelhor kernel: GEOM: da0: partition 1 does not end > >> on a track boundary. > >> Apr ?7 15:33:04 botelhor kernel: umass0: at uhub0, port 2, addr 2 > >> (disconnected) Apr ?7 15:33:04 botelhor kernel: (da1:umass-sim0:0:0:1): > >> Synchronize cache failed, status == 0x3f, scsi status == 0x0 > >> Apr ?7 15:33:04 botelhor kernel: (da0:umass-sim0:0:0:0): lost device > >> Apr ?7 15:33:04 botelhor kernel: (da0:umass-sim0:0:0:0): removing device > >> entry Apr ?7 15:33:04 botelhor kernel: (da1:umass-sim0:0:0:1): lost > >> device Apr ?7 15:33:04 botelhor kernel: (da1:umass-sim0:0:0:1): removing > >> device entry Apr ?7 15:33:04 botelhor kernel: ugen0.2: at > >> usbus0 (disconnected) > >> > >> Using 8.0-CURRENT r190550 > >> > >> I've tried on all usb ports, and have the same. Any idea? > > > > Your device probably needs the no synchronize cache quirk. See quirk > > table in /sys/dev/usb/storage/umass.c . > > Hans, > > I got it and can make tests here, but, i cannot find EZZE-E800GF or nothing > related on usbdevs, I don't know where this description came from. Could > you point me to the right place? > usbconfig dump_device_desc Look for idVendor and idProduct --HPS From gary.jennejohn at freenet.de Wed Apr 8 06:01:19 2009 From: gary.jennejohn at freenet.de (Gary Jennejohn) Date: Wed Apr 8 06:01:26 2009 Subject: AMD 780G chipset major issues 3/3 (btx) In-Reply-To: <20090408120531.F8569@rust.salford.ac.uk> References: <83e5fb980904061402q73940f8at4ec4b8f821354320@mail.gmail.com> <200904062321.47691.thierry.herbelot@free.fr> <20090407095804.G8569@rust.salford.ac.uk> <1239132158.1947.21.camel@balrog.2hip.net> <20090408120531.F8569@rust.salford.ac.uk> Message-ID: <20090408150113.5155b99b@ernst.jennejohn.org> On Wed, 8 Apr 2009 12:06:07 +0100 (BST) "Mark Powell" wrote: > On Tue, 7 Apr 2009, Robert Noland wrote: > > > I can't really speak for the other components, but afaik, all of the > > radeon IGPs should be working ok. I think it is an 780G that AMD is > > planning to send me once it gets approved as well... > > Do you know of any 780G MBs with 6xSATA, or preferably 8xSATA? > Cheers. > Well, not exactly what you wanted, but my GA-MA78GPM-DS2H has 5 SATA on the mobo and 1 eSATA on the back panel. --- Gary Jennejohn From ohartman at zedat.fu-berlin.de Wed Apr 8 06:44:25 2009 From: ohartman at zedat.fu-berlin.de (O. Hartmann) Date: Wed Apr 8 06:44:31 2009 Subject: firefox3 with high latencies when acting with mouse or keyboard and graphics refresh Message-ID: <49DCA9E0.6000109@zedat.fu-berlin.de> Hello, got a problem since yesterday after having done a lot of updates (ports): on all of my FreeBSD 8.0-CURRENT/amd64 boxes firefox does have enormous high latencies when typing in or moving the mouse or popping up the window icon or down. Since this happens on all of 8.0-CUR/amd boxes, I guess it has something to do with an upgrade of the ports. I reinstalled firefox twice, but without success, so I want to ask for some hints.. Regards, Oliver From sean.bruno at dsl-only.net Wed Apr 8 09:02:18 2009 From: sean.bruno at dsl-only.net (Sean Bruno) Date: Wed Apr 8 09:02:26 2009 Subject: PPC Macbook + Firewire In-Reply-To: <49DC8D7F.5070403@fgznet.ch> References: <1239169884.2625.4.camel@localhost.localdomain> <1239181170.2433.1935.camel@horst-tla> <49DC8D7F.5070403@fgznet.ch> Message-ID: <1239206536.7373.2.camel@localhost.localdomain> > > In case you meant the PowerBook (PPC based), attached a dmesg. > > Andreas Yup, I did mean the "PowerBook" :) > fwohci0: mem 0xf5000000-0xf5000fff irq 40 at device 14.0 on pci2 > fwohci0: [ITHREAD] > fwohci0: OHCI version 1.10 (ROM=0) > fwohci0: No. of Isochronous channels is 8. > fwohci0: EUI64 00:0d:93:ff:fe:35:b3:80 > fwohci0: invalid speed 7 (fixed to 3). > fwohci0: Phy 1394a available S800, 3 ports. > fwohci0: Link S800, max_rec 4096 bytes. > firewire0: on fwohci0 > fwe0: on firewire0 > if_fwe0: Fake Ethernet address: 02:0d:93:35:b3:80 > fwe0: Ethernet address: 02:0d:93:35:b3:80 > sbp0: on firewire0 > fwohci0: Initiate bus reset > fwohci0: fwohci_intr_core: BUS reset > fwohci0: fwohci_intr_core: node_id=0x00000001, SelfID Count=2, CYCLEMASTER mode > firewire0: fw_explore_nodePre 1394a-2000 detected > firewire0: fw_explore_node: fwdev->speed(S400) set lower than binfo->link_spd(S100) > firewire0: New S400 device ID:0001d200005b017a > sbp0: sbp_show_sdev_info: sbp0:0:0: ordered:1 type:0 EUI:0001d200005b017a node:0 speed:2 maxrec:0 > sbp0: sbp_show_sdev_info: sbp0:0:0 'Oxford Semiconductor Ltd. ' 'OXFORD IDE Device LUN 0 ' '000138' > da0 at sbp0 bus 0 target 0 lun 0 > da0: Fixed Simplified Direct Access SCSI-4 device > da0: 50.000MB/s transfers > da0: 131071MB (268435455 512 byte sectors: 255H 63S/T 16709C) This looks like a successful boot. Is everything working ok on your PowerBook then? Sea From rbgarga at gmail.com Wed Apr 8 09:02:50 2009 From: rbgarga at gmail.com (Renato Botelho) Date: Wed Apr 8 09:02:58 2009 Subject: new usb: mass storage error, Synchronize cache failed In-Reply-To: <200904081438.59388.hselasky@c2i.net> References: <747dc8f30904071139j32b55e2pf0fcd07a51c260a2@mail.gmail.com> <200904080816.09996.hselasky@c2i.net> <747dc8f30904080525p4e8dfe7fi15e6e758338467c8@mail.gmail.com> <200904081438.59388.hselasky@c2i.net> Message-ID: <747dc8f30904080902o1771b3e7i8ac24f1c4139c33d@mail.gmail.com> On Wed, Apr 8, 2009 at 9:38 AM, Hans Petter Selasky wrote: > On Wednesday 08 April 2009, Renato Botelho wrote: >> On Wed, Apr 8, 2009 at 3:16 AM, Hans Petter Selasky > wrote: >> > On Tuesday 07 April 2009, Renato Botelho wrote: >> >> When I plug a gradiente cell phone on my USB I got this: >> >> >> >> Apr ?7 15:33:01 botelhor root: Unknown USB device: vendor 0x0e8d >> >> product 0x0002 bus uhub0 >> >> Apr ?7 15:33:01 botelhor kernel: ugen0.2: at usbus0 >> >> Apr ?7 15:33:01 botelhor kernel: umass0: on usbus0 >> >> Apr ?7 15:33:01 botelhor kernel: umass0: ?SCSI over Bulk-Only; quirks = >> >> 0x0000 Apr ?7 15:33:02 botelhor kernel: umass0:0:0:-1: Attached to >> >> scbus0 Apr ?7 15:33:02 botelhor kernel: da0 at umass-sim0 bus 0 target 0 >> >> lun 0 Apr 7 15:33:02 botelhor kernel: da0: Removable Direct >> >> Access SCSI-0 device >> >> Apr ?7 15:33:02 botelhor kernel: da0: 1.000MB/s transfers >> >> Apr ?7 15:33:02 botelhor kernel: da0: 982MB (2012160 512 byte sectors: >> >> 64H 32S/T 982C) >> >> Apr ?7 15:33:02 botelhor kernel: da1 at umass-sim0 bus 0 target 0 lun 1 >> >> Apr ?7 15:33:02 botelhor kernel: da1: Removable Direct >> >> Access SCSI-0 device >> >> Apr ?7 15:33:02 botelhor kernel: da1: 1.000MB/s transfers >> >> Apr ?7 15:33:02 botelhor kernel: da1: 1MB (3668 512 byte sectors: 64H >> >> 32S/T 1C) Apr ?7 15:33:02 botelhor kernel: GEOM: da0: partition 1 does >> >> not start on a track boundary. >> >> Apr ?7 15:33:02 botelhor kernel: GEOM: da0: partition 1 does not end >> >> on a track boundary. >> >> Apr ?7 15:33:04 botelhor kernel: umass0: at uhub0, port 2, addr 2 >> >> (disconnected) Apr ?7 15:33:04 botelhor kernel: (da1:umass-sim0:0:0:1): >> >> Synchronize cache failed, status == 0x3f, scsi status == 0x0 >> >> Apr ?7 15:33:04 botelhor kernel: (da0:umass-sim0:0:0:0): lost device >> >> Apr ?7 15:33:04 botelhor kernel: (da0:umass-sim0:0:0:0): removing device >> >> entry Apr ?7 15:33:04 botelhor kernel: (da1:umass-sim0:0:0:1): lost >> >> device Apr ?7 15:33:04 botelhor kernel: (da1:umass-sim0:0:0:1): removing >> >> device entry Apr ?7 15:33:04 botelhor kernel: ugen0.2: at >> >> usbus0 (disconnected) >> >> >> >> Using 8.0-CURRENT r190550 >> >> >> >> I've tried on all usb ports, and have the same. Any idea? >> > >> > Your device probably needs the no synchronize cache quirk. See quirk >> > table in /sys/dev/usb/storage/umass.c . >> >> Hans, >> >> I got it and can make tests here, but, i cannot find EZZE-E800GF or nothing >> related on usbdevs, I don't know where this description came from. Could >> you point me to the right place? >> > > usbconfig dump_device_desc > > Look for idVendor and idProduct I did it: ugen1.2: at usbus1, cfg=0 md=HOST spd=FULL (12Mbps) pwr=ON bLength = 0x0012 bDescriptorType = 0x0001 bcdUSB = 0x0110 bDeviceClass = 0x0000 bDeviceSubClass = 0x0000 bDeviceProtocol = 0x0000 bMaxPacketSize0 = 0x0008 idVendor = 0x0e8d idProduct = 0x0002 bcdDevice = 0x0001 iManufacturer = 0x0002 iProduct = 0x0003 iSerialNumber = 0x0004 <53923610014483f> bNumConfigurations = 0x0001 And I created attached patch but nothing different happened, when I plug usb in, the same result. Thanks -- Renato Botelho -------------- next part -------------- A non-text attachment was scrubbed... Name: usb.diff Type: application/octet-stream Size: 1201 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20090408/23a46b97/usb.obj From nork at FreeBSD.org Wed Apr 8 09:05:51 2009 From: nork at FreeBSD.org (Norikatsu Shigemura) Date: Wed Apr 8 09:05:58 2009 Subject: ZFS checksum errors on USB attach (Was: ZFS data error without reasons) In-Reply-To: <012d01c9b706$ccace720$6606b560$@Sparrevohn@btinternet.com> References: <49BD117B.2080706@163.com> <20090331100328.H46640@rust.salford.ac.uk> <20090401044011.GA51164@plebeian.afflictions.org> <200904010846.55770.hselasky@c2i.net> <20090401121704.GA92522@plebeian.afflictions.org> <20090401234315.GA11125@plebeian.afflictions.org> <20090405015627.GB47968@plebeian.afflictions.org> <012d01c9b706$ccace720$6606b560$@Sparrevohn@btinternet.com> Message-ID: <20090409003108.fe768d54.nork@FreeBSD.org> Hi jhb! I got ZFS checksum error issue, too. So I found a way of fixing this issue. Please back out following change. sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_dir.c - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - revision 1.5 date: 2009/03/18 16:19:44; author: jhb; state: Exp; lines: +2 -0 SVN rev 189967 on 2009-03-18 16:19:44Z by jhb The zfs_get_xattrdir() function is used to find the extended attribute directory for a znode. When the directory already exists, it returns a referenced but unlocked vnode. When a directory does not yet exist, it calls zfs_make_xattrdir() to create a new one. zfs_make_xattrdir() returns the vnode both referenced and and locked and zfs_get_xattrdir() was leaking this vnode lock to its callers. Fix this by dropping the vnode lock if zfs_make_xattrdir() successfully creates a new extended attribute directory. Reviewed by: pjd - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - [Validation] 1. I got ZFS checksum error issue 2. Backup 3. Restructure ZPool 4. Restore (But ZFS checksum error) 5. Restructure ZPool with kern.smp.disabled=1 (Almost good, but...) 6. Restore 7. Backout zfs_dir#1.5 8. Good works for me I tested many backup&restore:-). On Mon, 6 Apr 2009 23:26:57 +0100 "Thomas Sparrevohn" wrote: > Just a me too - Here - I just seen significant corruption of a newly > restored pool - the system had been running a portupgrade - I am getting > worried - but the disks shows no errors - neither from the ATA subsystem nor > from smartctl or some vendor testing tools I have > -----Original Message----- > From: owner-freebsd-current@freebsd.org > [mailto:owner-freebsd-current@freebsd.org] On Behalf Of Damian Gerow > Sent: 05 April 2009 02:56 > To: freebsd-current@freebsd.org > Subject: Re: ZFS checksum errors on USB attach (Was: ZFS data error without > reasons) > I've filed kern/133373 to track this. From barney_cordoba at yahoo.com Wed Apr 8 09:27:41 2009 From: barney_cordoba at yahoo.com (Barney Cordoba) Date: Wed Apr 8 09:27:48 2009 Subject: Are wakeups cumulative? Message-ID: <508110.15906.qm@web63902.mail.re1.yahoo.com> If a wakeup() call is issued and the thread isn't sleeping, will it the wakeup be issued immediately when it does sleep, or is the wakeup discarded? Also if multiple wakeups are issues before wakeup is the thread only woken once? Barney From M.S.Powell at salford.ac.uk Wed Apr 8 09:36:22 2009 From: M.S.Powell at salford.ac.uk (Mark Powell) Date: Wed Apr 8 09:36:29 2009 Subject: ATA related panic during ZFS scrub Message-ID: <20090408170231.K38445@rust.salford.ac.uk> Hi, Got a panic I'd not seen before, yesterday, whilst scrubbing one of two pools, to fix the apparently spurious CRC errors highlighted here: http://kerneltrap.org/mailarchive/freebsd-current/2009/4/7/5428764 4GB RAM amd64 8.0-CURRENT FreeBSD 8.0-CURRENT #0 r190198M: Sat Mar 21 16:13:09 GMT 2009 / is ufs on USB key Sorry, but I don't have a serial console or dump device valid in a panic. Here are screenshots: http://www.rootshell.be/~msp/IMG_4393.JPG Here's the edited gocr of the above: ----- Fatal trap 9 general protection fault while in kernel mode cpuid -- 1; apic id = 01 instruction pointer = Ox8:Oxffffffff807db306 stack pointer = Ox10:OxfffffffeeS79faaO frame pointer = 0x10:Oxfffffffee579faeO Code Segment = base Ox0, limit Oxfffff, type Ox1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags = interrupt enabled, resume, IOPL O current process = 12 (irq19: atacpi1++) [thread pid 12 tid 100032 ] Stopped at bcopy+Ox16 repe movsq (%rsi),%es:(%rdi) db> lock order reversal; (Giant after non-sleepable) lst Oxffffff000lebS900 ATA 6tate l0ck (T state I0ckI /po01/frggb6dg/ugr/src/hg ad/6y6/deu/8t8/8ta-aIl.c355 2nd Oxffffffff80bB68cO Giant (i8nt7 /pooI/freebsd8/u6r/src/hegd/sy6/dg4bdw/kbdx.cl044 KDB; stack backtrace db_trace_self_wrapper() at db trace_self_wrapper+0x2a _witness_debugger() at _witness_debugger+Ox49 witness_checkorder() at witness_checkorder+0x7ea _mtx_lock_flags() at _mtx_lock_flags+Ox68 kbdmux_ioctl() at kbdmux_ioctl+Ox101 sc_cngetc() at sc_cngetc+Oxc1 cncheckc() at cncheckc+0x65 cngetc() at cngetc+0x1c ----- http://www.rootshell.be/~msp/IMG_4395.JPG http://www.rootshell.be/~msp/IMG_4397.JPG Someone suggested that this and/or the problems, in the other thread above, could be related to a bug in bounce buffers which occurs quite rarely, but is causing writing the wrong blocks or data? I did previously have bounce buffers: # sysctl -a | grep bounced hw.busdma.zone0.total_bounced: 92814775 I'm going to try running with hw.physmem="3400M" to avoid bounce buffers on my hardware. Cheers. -- Mark Powell - UNIX System Administrator - The University of Salford Information & Learning Services, Clifford Whitworth Building, Salford University, Manchester, M5 4WT, UK. Tel: +44 161 295 6843 Fax: +44 161 295 5888 www.pgp.com for PGP key From jkim at FreeBSD.org Wed Apr 8 09:57:28 2009 From: jkim at FreeBSD.org (Jung-uk Kim) Date: Wed Apr 8 09:57:35 2009 Subject: AMD 780G chipset major issues 1/3 (ata, ataati) In-Reply-To: <83e5fb980904080424w1dda7fb3tf1c26ac72752352f@mail.gmail.com> References: <1239063789.00097213.1239052203@10.7.7.3> <200904071757.04734.jkim@FreeBSD.org> <83e5fb980904080424w1dda7fb3tf1c26ac72752352f@mail.gmail.com> Message-ID: <200904081257.18260.jkim@FreeBSD.org> On Wednesday 08 April 2009 07:24 am, Diego Depaoli wrote: > On Tue, Apr 7, 2009 at 11:57 PM, Jung-uk Kim wrote: > > I have a similar board and it seems to share the broken ACPI > > DSDT. > > At this point I consider acpi's issues very minor issues. > The hard reality is than I can't install and run FreeBSD out of the > box on such board bought in the last five years (and I do not ever > buy products just released on the market). These days ACPI does a lot more than you may think. ;-) Actually, the BIOS writer *tried* to configure SATA controller modes differently depending on BIOS options you have selected when DSDT is loaded but that is one of the things ignored if my assumption was correct, i.e., sharing broken DSDT. Try dumping DSDT and see it for yourself. You may see something like this: Device (SATA) { Name (_ADR, 0x00110000) If (LEqual (STCL, 0x0101)) <--- "executable at module level" { ... <--- This entire block is ignored! } } Within the block, it sets PCI BARs and stuff for atapci0 and enables its channels via _STA methods. Without the south bridge documentation[1], we cannot do anything to mimic what it does from ataati(4). Jung-uk Kim [1] The situation may change in the future, though: http://forums.amd.com/devforum/messageview.cfm?catid=203&threadid=110538 From andreast-list at fgznet.ch Wed Apr 8 10:03:02 2009 From: andreast-list at fgznet.ch (Andreas Tobler) Date: Wed Apr 8 10:03:16 2009 Subject: PPC Macbook + Firewire In-Reply-To: <1239206536.7373.2.camel@localhost.localdomain> References: <1239169884.2625.4.camel@localhost.localdomain> <1239181170.2433.1935.camel@horst-tla> <49DC8D7F.5070403@fgznet.ch> <1239206536.7373.2.camel@localhost.localdomain> Message-ID: <49DCD8BB.10702@fgznet.ch> Sean Bruno wrote: >> In case you meant the PowerBook (PPC based), attached a dmesg. >> >> Andreas > > Yup, I did mean the "PowerBook" :) > >> fwohci0: mem 0xf5000000-0xf5000fff irq 40 at device 14.0 on pci2 >> fwohci0: [ITHREAD] >> fwohci0: OHCI version 1.10 (ROM=0) >> fwohci0: No. of Isochronous channels is 8. >> fwohci0: EUI64 00:0d:93:ff:fe:35:b3:80 >> fwohci0: invalid speed 7 (fixed to 3). >> fwohci0: Phy 1394a available S800, 3 ports. >> fwohci0: Link S800, max_rec 4096 bytes. >> firewire0: on fwohci0 >> fwe0: on firewire0 >> if_fwe0: Fake Ethernet address: 02:0d:93:35:b3:80 >> fwe0: Ethernet address: 02:0d:93:35:b3:80 >> sbp0: on firewire0 >> fwohci0: Initiate bus reset >> fwohci0: fwohci_intr_core: BUS reset >> fwohci0: fwohci_intr_core: node_id=0x00000001, SelfID Count=2, CYCLEMASTER mode > >> firewire0: fw_explore_nodePre 1394a-2000 detected >> firewire0: fw_explore_node: fwdev->speed(S400) set lower than binfo->link_spd(S100) >> firewire0: New S400 device ID:0001d200005b017a >> sbp0: sbp_show_sdev_info: sbp0:0:0: ordered:1 type:0 EUI:0001d200005b017a node:0 speed:2 maxrec:0 >> sbp0: sbp_show_sdev_info: sbp0:0:0 'Oxford Semiconductor Ltd. ' 'OXFORD IDE Device LUN 0 ' '000138' > >> da0 at sbp0 bus 0 target 0 lun 0 >> da0: Fixed Simplified Direct Access SCSI-4 device >> da0: 50.000MB/s transfers >> da0: 131071MB (268435455 512 byte sectors: 255H 63S/T 16709C) > > > This looks like a successful boot. Is everything working ok on your > PowerBook then? Yes, I boot from the fw disk, nothing else. But I do not work that often on this PowerBook. I plan to upgrade tonight to a current snapshot. I'll let you know if I have some oddities. Andreas From dchagin at freebsd.org Wed Apr 8 10:10:55 2009 From: dchagin at freebsd.org (Chagin Dmitry) Date: Wed Apr 8 10:11:04 2009 Subject: Are wakeups cumulative? In-Reply-To: <508110.15906.qm@web63902.mail.re1.yahoo.com> References: <508110.15906.qm@web63902.mail.re1.yahoo.com> Message-ID: <20090408164832.GA15890@dchagin.static.corbina.ru> On Wed, Apr 08, 2009 at 09:27:40AM -0700, Barney Cordoba wrote: > > If a wakeup() call is issued and the thread isn't sleeping, will it > the wakeup be issued immediately when it does sleep, or is the wakeup > discarded? > you will lose wakeup. > Also if multiple wakeups are issues before wakeup is the thread only > woken once? > hehe, rtfm. > Barney > > > > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" -- Have fun! chd -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 196 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20090408/070ba230/attachment.pgp From kevinxlinuz at 163.com Wed Apr 8 10:16:54 2009 From: kevinxlinuz at 163.com (kevin) Date: Wed Apr 8 10:17:01 2009 Subject: ZFS checksum errors on USB attach (Was: ZFS data error without reasons) In-Reply-To: <20090409003108.fe768d54.nork@FreeBSD.org> References: <49BD117B.2080706@163.com> <20090331100328.H46640@rust.salford.ac.uk> <20090401044011.GA51164@plebeian.afflictions.org> <200904010846.55770.hselasky@c2i.net> <20090401121704.GA92522@plebeian.afflictions.org> <20090401234315.GA11125@plebeian.afflictions.org> <20090405015627.GB47968@plebeian.afflictions.org> <012d01c9b706$ccace720$6606b560$@Sparrevohn@btinternet.com> <20090409003108.fe768d54.nork@FreeBSD.org> Message-ID: <49DCDBF6.5040700@163.com> Norikatsu Shigemura wrote: > Hi jhb! > > I got ZFS checksum error issue, too. So I found a way of fixing > this issue. Please back out following change. > > sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_dir.c > - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - > revision 1.5 > date: 2009/03/18 16:19:44; author: jhb; state: Exp; lines: +2 -0 > SVN rev 189967 on 2009-03-18 16:19:44Z by jhb > > The zfs_get_xattrdir() function is used to find the extended attribute > directory for a znode. When the directory already exists, it returns a > referenced but unlocked vnode. When a directory does not yet exist, it > calls zfs_make_xattrdir() to create a new one. zfs_make_xattrdir() returns > the vnode both referenced and and locked and zfs_get_xattrdir() was leaking > this vnode lock to its callers. Fix this by dropping the vnode lock if > zfs_make_xattrdir() successfully creates a new extended attribute > directory. > > Reviewed by: pjd > - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - > > [Validation] > 1. I got ZFS checksum error issue > 2. Backup > 3. Restructure ZPool > 4. Restore (But ZFS checksum error) > 5. Restructure ZPool with kern.smp.disabled=1 > (Almost good, but...) > 6. Restore > 7. Backout zfs_dir#1.5 > 8. Good works for me > > I tested many backup&restore:-). > > On Mon, 6 Apr 2009 23:26:57 +0100 > "Thomas Sparrevohn" wrote: > >> Just a me too - Here - I just seen significant corruption of a newly >> restored pool - the system had been running a portupgrade - I am getting >> worried - but the disks shows no errors - neither from the ATA subsystem nor >> from smartctl or some vendor testing tools I have >> It just fix some case.Have you tried to import a zpool on a usb hard disk? Thanks, kevin From nork at FreeBSD.org Wed Apr 8 10:28:23 2009 From: nork at FreeBSD.org (Norikatsu Shigemura) Date: Wed Apr 8 10:28:29 2009 Subject: ZFS checksum errors on USB attach (Was: ZFS data error without reasons) In-Reply-To: <49DCDBF6.5040700@163.com> References: <49BD117B.2080706@163.com> <20090331100328.H46640@rust.salford.ac.uk> <20090401044011.GA51164@plebeian.afflictions.org> <200904010846.55770.hselasky@c2i.net> <20090401121704.GA92522@plebeian.afflictions.org> <20090401234315.GA11125@plebeian.afflictions.org> <20090405015627.GB47968@plebeian.afflictions.org> <012d01c9b706$ccace720$6606b560$@Sparrevohn@btinternet.com> <20090409003108.fe768d54.nork@FreeBSD.org> <49DCDBF6.5040700@163.com> Message-ID: <20090409022802.d11badc5.nork@FreeBSD.org> Hi kevin. On Thu, 09 Apr 2009 01:16:38 +0800 kevin wrote: > It just fix some case.Have you tried to import a zpool on a usb hard disk? I haven't tried to import a zpool from usb hard disk. But I used usb hard disk to backup&restore with ufs like following: # tar -cvf /usbhdd/backup.tar -C / : # zpool destroy tank # zpool create tank mirror ad4p2 ad8p2 : # tar -xpvf /usbhdd/backup.tar From hselasky at c2i.net Wed Apr 8 11:31:01 2009 From: hselasky at c2i.net (Hans Petter Selasky) Date: Wed Apr 8 11:31:08 2009 Subject: new usb: mass storage error, Synchronize cache failed In-Reply-To: <747dc8f30904080902o1771b3e7i8ac24f1c4139c33d@mail.gmail.com> References: <747dc8f30904071139j32b55e2pf0fcd07a51c260a2@mail.gmail.com> <200904081438.59388.hselasky@c2i.net> <747dc8f30904080902o1771b3e7i8ac24f1c4139c33d@mail.gmail.com> Message-ID: <200904082033.30722.hselasky@c2i.net> On Wednesday 08 April 2009, Renato Botelho wrote: > On Wed, Apr 8, 2009 at 9:38 AM, Hans Petter Selasky wrote: > > On Wednesday 08 April 2009, Renato Botelho wrote: > >> On Wed, Apr 8, 2009 at 3:16 AM, Hans Petter Selasky > > > > wrote: > >> > On Tuesday 07 April 2009, Renato Botelho wrote: > >> >> When I plug a gradiente cell phone on my USB I got this: > >> >> > >> >> Apr ?7 15:33:01 botelhor root: Unknown USB device: vendor 0x0e8d > >> >> product 0x0002 bus uhub0 > >> >> Apr ?7 15:33:01 botelhor kernel: ugen0.2: at usbus0 > >> >> Apr ?7 15:33:01 botelhor kernel: umass0: on usbus0 > >> >> Apr ?7 15:33:01 botelhor kernel: umass0: ?SCSI over Bulk-Only; quirks > >> >> = 0x0000 Apr ?7 15:33:02 botelhor kernel: umass0:0:0:-1: Attached to > >> >> scbus0 Apr ?7 15:33:02 botelhor kernel: da0 at umass-sim0 bus 0 > >> >> target 0 lun 0 Apr 7 15:33:02 botelhor kernel: da0: > >> >> Removable Direct Access SCSI-0 device > >> >> Apr ?7 15:33:02 botelhor kernel: da0: 1.000MB/s transfers > >> >> Apr ?7 15:33:02 botelhor kernel: da0: 982MB (2012160 512 byte > >> >> sectors: 64H 32S/T 982C) > >> >> Apr ?7 15:33:02 botelhor kernel: da1 at umass-sim0 bus 0 target 0 lun > >> >> 1 Apr ?7 15:33:02 botelhor kernel: da1: Removable Direct > >> >> Access SCSI-0 device > >> >> Apr ?7 15:33:02 botelhor kernel: da1: 1.000MB/s transfers > >> >> Apr ?7 15:33:02 botelhor kernel: da1: 1MB (3668 512 byte sectors: 64H > >> >> 32S/T 1C) Apr ?7 15:33:02 botelhor kernel: GEOM: da0: partition 1 > >> >> does not start on a track boundary. > >> >> Apr ?7 15:33:02 botelhor kernel: GEOM: da0: partition 1 does not end > >> >> on a track boundary. > >> >> Apr ?7 15:33:04 botelhor kernel: umass0: at uhub0, port 2, addr 2 > >> >> (disconnected) Apr ?7 15:33:04 botelhor kernel: > >> >> (da1:umass-sim0:0:0:1): Synchronize cache failed, status == 0x3f, > >> >> scsi status == 0x0 Apr ?7 15:33:04 botelhor kernel: > >> >> (da0:umass-sim0:0:0:0): lost device Apr ?7 15:33:04 botelhor kernel: > >> >> (da0:umass-sim0:0:0:0): removing device entry Apr ?7 15:33:04 > >> >> botelhor kernel: (da1:umass-sim0:0:0:1): lost device Apr ?7 15:33:04 > >> >> botelhor kernel: (da1:umass-sim0:0:0:1): removing device entry Apr ?7 > >> >> 15:33:04 botelhor kernel: ugen0.2: at usbus0 > >> >> (disconnected) > >> >> > >> >> Using 8.0-CURRENT r190550 > >> >> > >> >> I've tried on all usb ports, and have the same. Any idea? > >> > > >> > Your device probably needs the no synchronize cache quirk. See quirk > >> > table in /sys/dev/usb/storage/umass.c . > >> > >> Hans, > >> > >> I got it and can make tests here, but, i cannot find EZZE-E800GF or > >> nothing related on usbdevs, I don't know where this description came > >> from. Could you point me to the right place? > > > > usbconfig dump_device_desc > > > > Look for idVendor and idProduct > > I did it: > > ugen1.2: at usbus1, cfg=0 md=HOST spd=FULL (12Mbps) > pwr=ON > > bLength = 0x0012 > bDescriptorType = 0x0001 > bcdUSB = 0x0110 > bDeviceClass = 0x0000 > bDeviceSubClass = 0x0000 > bDeviceProtocol = 0x0000 > bMaxPacketSize0 = 0x0008 > idVendor = 0x0e8d > idProduct = 0x0002 > bcdDevice = 0x0001 > iManufacturer = 0x0002 > iProduct = 0x0003 > iSerialNumber = 0x0004 <53923610014483f> > bNumConfigurations = 0x0001 > > And I created attached patch but nothing different happened, > when I plug usb in, the same result. Did you recompile umass and/or kernel ? --HPS From rbgarga at gmail.com Wed Apr 8 11:42:18 2009 From: rbgarga at gmail.com (Renato Botelho) Date: Wed Apr 8 11:42:26 2009 Subject: new usb: mass storage error, Synchronize cache failed In-Reply-To: <200904082033.30722.hselasky@c2i.net> References: <747dc8f30904071139j32b55e2pf0fcd07a51c260a2@mail.gmail.com> <200904081438.59388.hselasky@c2i.net> <747dc8f30904080902o1771b3e7i8ac24f1c4139c33d@mail.gmail.com> <200904082033.30722.hselasky@c2i.net> Message-ID: <747dc8f30904081142r704bb155q8fc8bbb37a30322f@mail.gmail.com> On Wed, Apr 8, 2009 at 3:33 PM, Hans Petter Selasky wrote: > On Wednesday 08 April 2009, Renato Botelho wrote: >> On Wed, Apr 8, 2009 at 9:38 AM, Hans Petter Selasky > wrote: >> > On Wednesday 08 April 2009, Renato Botelho wrote: >> >> On Wed, Apr 8, 2009 at 3:16 AM, Hans Petter Selasky >> > >> > wrote: >> >> > On Tuesday 07 April 2009, Renato Botelho wrote: >> >> >> When I plug a gradiente cell phone on my USB I got this: >> >> >> >> >> >> Apr ?7 15:33:01 botelhor root: Unknown USB device: vendor 0x0e8d >> >> >> product 0x0002 bus uhub0 >> >> >> Apr ?7 15:33:01 botelhor kernel: ugen0.2: at usbus0 >> >> >> Apr ?7 15:33:01 botelhor kernel: umass0: on usbus0 >> >> >> Apr ?7 15:33:01 botelhor kernel: umass0: ?SCSI over Bulk-Only; quirks >> >> >> = 0x0000 Apr ?7 15:33:02 botelhor kernel: umass0:0:0:-1: Attached to >> >> >> scbus0 Apr ?7 15:33:02 botelhor kernel: da0 at umass-sim0 bus 0 >> >> >> target 0 lun 0 Apr 7 15:33:02 botelhor kernel: da0: >> >> >> Removable Direct Access SCSI-0 device >> >> >> Apr ?7 15:33:02 botelhor kernel: da0: 1.000MB/s transfers >> >> >> Apr ?7 15:33:02 botelhor kernel: da0: 982MB (2012160 512 byte >> >> >> sectors: 64H 32S/T 982C) >> >> >> Apr ?7 15:33:02 botelhor kernel: da1 at umass-sim0 bus 0 target 0 lun >> >> >> 1 Apr ?7 15:33:02 botelhor kernel: da1: Removable Direct >> >> >> Access SCSI-0 device >> >> >> Apr ?7 15:33:02 botelhor kernel: da1: 1.000MB/s transfers >> >> >> Apr ?7 15:33:02 botelhor kernel: da1: 1MB (3668 512 byte sectors: 64H >> >> >> 32S/T 1C) Apr ?7 15:33:02 botelhor kernel: GEOM: da0: partition 1 >> >> >> does not start on a track boundary. >> >> >> Apr ?7 15:33:02 botelhor kernel: GEOM: da0: partition 1 does not end >> >> >> on a track boundary. >> >> >> Apr ?7 15:33:04 botelhor kernel: umass0: at uhub0, port 2, addr 2 >> >> >> (disconnected) Apr ?7 15:33:04 botelhor kernel: >> >> >> (da1:umass-sim0:0:0:1): Synchronize cache failed, status == 0x3f, >> >> >> scsi status == 0x0 Apr ?7 15:33:04 botelhor kernel: >> >> >> (da0:umass-sim0:0:0:0): lost device Apr ?7 15:33:04 botelhor kernel: >> >> >> (da0:umass-sim0:0:0:0): removing device entry Apr ?7 15:33:04 >> >> >> botelhor kernel: (da1:umass-sim0:0:0:1): lost device Apr ?7 15:33:04 >> >> >> botelhor kernel: (da1:umass-sim0:0:0:1): removing device entry Apr ?7 >> >> >> 15:33:04 botelhor kernel: ugen0.2: at usbus0 >> >> >> (disconnected) >> >> >> >> >> >> Using 8.0-CURRENT r190550 >> >> >> >> >> >> I've tried on all usb ports, and have the same. Any idea? >> >> > >> >> > Your device probably needs the no synchronize cache quirk. See quirk >> >> > table in /sys/dev/usb/storage/umass.c . >> >> >> >> Hans, >> >> >> >> I got it and can make tests here, but, i cannot find EZZE-E800GF or >> >> nothing related on usbdevs, I don't know where this description came >> >> from. Could you point me to the right place? >> > >> > usbconfig dump_device_desc >> > >> > Look for idVendor and idProduct >> >> I did it: >> >> ugen1.2: at usbus1, cfg=0 md=HOST spd=FULL (12Mbps) >> pwr=ON >> >> ? bLength = 0x0012 >> ? bDescriptorType = 0x0001 >> ? bcdUSB = 0x0110 >> ? bDeviceClass = 0x0000 >> ? bDeviceSubClass = 0x0000 >> ? bDeviceProtocol = 0x0000 >> ? bMaxPacketSize0 = 0x0008 >> ? idVendor = 0x0e8d >> ? idProduct = 0x0002 >> ? bcdDevice = 0x0001 >> ? iManufacturer = 0x0002 ? >> ? iProduct = 0x0003 ? >> ? iSerialNumber = 0x0004 ?<53923610014483f> >> ? bNumConfigurations = 0x0001 >> >> And I created attached patch but nothing different happened, >> when I plug usb in, the same result. > > Did you recompile umass and/or kernel ? Since I was on old-than-my-src version, I rebuilt world and kernel with r190843 -- Renato Botelho From hselasky at c2i.net Wed Apr 8 11:46:39 2009 From: hselasky at c2i.net (Hans Petter Selasky) Date: Wed Apr 8 11:46:46 2009 Subject: new usb: mass storage error, Synchronize cache failed In-Reply-To: <747dc8f30904081142r704bb155q8fc8bbb37a30322f@mail.gmail.com> References: <747dc8f30904071139j32b55e2pf0fcd07a51c260a2@mail.gmail.com> <200904082033.30722.hselasky@c2i.net> <747dc8f30904081142r704bb155q8fc8bbb37a30322f@mail.gmail.com> Message-ID: <200904082049.09103.hselasky@c2i.net> On Wednesday 08 April 2009, Renato Botelho wrote: > On Wed, Apr 8, 2009 at 3:33 PM, Hans Petter Selasky wrote: > Since I was on old-than-my-src version, I rebuilt > world and kernel with r190843 And what is the dmesg after patching? --HPS From ivoras at freebsd.org Wed Apr 8 12:15:20 2009 From: ivoras at freebsd.org (Ivan Voras) Date: Wed Apr 8 12:15:27 2009 Subject: kbdmux vs ATA? (was: ATA related panic during ZFS scrub) In-Reply-To: <20090408170231.K38445@rust.salford.ac.uk> References: <20090408170231.K38445@rust.salford.ac.uk> Message-ID: Mark Powell wrote: > Hi, > Got a panic I'd not seen before, yesterday, whilst scrubbing one of > two pools, to fix the apparently spurious CRC errors highlighted here: > > http://kerneltrap.org/mailarchive/freebsd-current/2009/4/7/5428764 > > 4GB RAM amd64 > > 8.0-CURRENT FreeBSD 8.0-CURRENT #0 r190198M: Sat Mar 21 16:13:09 GMT 2009 > > > Sorry, but I don't have a serial console or dump device valid in a > panic. Here are screenshots: > > http://www.rootshell.be/~msp/IMG_4393.JPG Hmmm, this shows a lock order problem between ATA and kbdmux's Giant. > / is ufs on USB key Are you saying the system has only USB drives or that the ZFS pool was on the USB drive (or something else)? In any case, USB drives do not appear as ATA drives. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 258 bytes Desc: OpenPGP digital signature Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20090408/4bcd8915/signature.pgp From ed at 80386.nl Wed Apr 8 12:33:21 2009 From: ed at 80386.nl (Ed Schouten) Date: Wed Apr 8 12:33:28 2009 Subject: kbdmux vs ATA? (was: ATA related panic during ZFS scrub) In-Reply-To: References: <20090408170231.K38445@rust.salford.ac.uk> Message-ID: <20090408193319.GK32098@hoeg.nl> * Ivan Voras wrote: > Hmmm, this shows a lock order problem between ATA and kbdmux's Giant. The current state of the input layer is a mess. I guess the policy was to not pick up any locks while in the debugger. Picking up Giant there is one of the most awful things that can happen, right? -- Ed Schouten WWW: http://80386.nl/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20090408/b1c2bab0/attachment.pgp From trebestie at gmail.com Wed Apr 8 12:37:40 2009 From: trebestie at gmail.com (Diego Depaoli) Date: Wed Apr 8 12:37:47 2009 Subject: AMD 780G chipset major issues 3/3 (btx) In-Reply-To: <200904071026.26735.jhb@freebsd.org> References: <83e5fb980904061402q73940f8at4ec4b8f821354320@mail.gmail.com> <200904071026.26735.jhb@freebsd.org> Message-ID: <83e5fb980904081237u4e2979b9tad38d62a061d85b8@mail.gmail.com> On Tue, Apr 7, 2009 at 4:26 PM, John Baldwin wrote: > On Monday 06 April 2009 5:02:53 pm Diego Depaoli wrote: >> And finally... >> if I enable ahci in bios the system won't boot ?with btx halted. >> Ctrl+alt+del is the only allowed action. >> >> Yes... it's a low cost motherboard, but I'm a bit confused. > > What OS release are you running? 8.0-CURRENT FreeBSD 8.0-CURRENT #19: Sun Apr 5 02:25:34 CEST 2009 FreeBSD version 800074 -- Diego Depaoli From dfr at rabson.org Wed Apr 8 12:38:37 2009 From: dfr at rabson.org (Doug Rabson) Date: Wed Apr 8 12:38:44 2009 Subject: NFS lockd/statd lock up network connection In-Reply-To: <49D851FC.4090103@sdf.lonestar.org> References: <49D851FC.4090103@sdf.lonestar.org> Message-ID: On 5 Apr 2009, at 07:38, Tom McLaughlin wrote: > Hey, I have a recent -CURRENT box which has a mount exported from an > OpenBSD NFS server. Recently I enabled lockd and statd on the machine > but this has started to cause the network connection on the machine > to lockup. I find the following in dmesg: > > nfs server exports:/mnt/raid0/net/home: lockd not responding > nfs server exports:/mnt/raid0/net/home: lockd not responding > nfs server exports:/mnt/raid0/net/home: lockd not responding > nfs server exports:/mnt/raid0/net/home: lockd not responding > nfs server exports:/mnt/raid0/net/home: lockd not responding > nfs server exports:/mnt/raid0/net/home: lockd not responding > nfs server exports:/mnt/raid0/net/home: lockd not responding > nfs server exports:/mnt/raid0/net/home: lockd not responding > NLM: failed to contact remote rpcbind, stat = 5, port = 28416 > > Additionally I see this when trying to restart netif: > > em0: Could not setup receive structures > > I've tried building with NFS_LEGACYRPC but that has not changed > anything. Additionally I've tested this on 7-STABLE and while lockd > still does not work (so, looks like I'll still have to work around > my need for NFS locking) the network connection at least does not > lock up. Is what I'm seeing evidence of some further problem? It looks as if lockd is not running on the server. The NFS locking protocol needs it enabled at both ends. Also, NFS_LEGACYRPC won't affect this - the record locking code always uses the new RPC code. From rwatson at FreeBSD.org Wed Apr 8 12:38:47 2009 From: rwatson at FreeBSD.org (Robert Watson) Date: Wed Apr 8 12:38:57 2009 Subject: kbdmux vs ATA? (was: ATA related panic during ZFS scrub) In-Reply-To: <20090408193319.GK32098@hoeg.nl> References: <20090408170231.K38445@rust.salford.ac.uk> <20090408193319.GK32098@hoeg.nl> Message-ID: On Wed, 8 Apr 2009, Ed Schouten wrote: > * Ivan Voras wrote: >> Hmmm, this shows a lock order problem between ATA and kbdmux's Giant. > > The current state of the input layer is a mess. I guess the policy was to > not pick up any locks while in the debugger. Picking up Giant there is one > of the most awful things that can happen, right? As a general rule, the low-level console interfaces should acquire at most spinlocks in normal operation (cngetc, cnputc, etc), and no locks at all when in the debugger (kdb_active). The reason for the second rule should be obvious, but the reason for the first rule is less obvious: it's called during the boot in all kinds of sensitive places as a result of calls to printf(9), so has to be willing to run under the most sticky of circumstances. Robert N M Watson Computer Laboratory University of Cambridge From ggajic at afrodita.rcub.bg.ac.yu Wed Apr 8 11:20:01 2009 From: ggajic at afrodita.rcub.bg.ac.yu (Goran Gajic) Date: Wed Apr 8 12:52:27 2009 Subject: Root mount fails again. CAM related? Message-ID: When I have reverted back change svn commit: r190677 head/sys: cam geom my system boots normaly again. This commit caused my system to hang with message Root mount waiting for ... gg. From rbgarga at gmail.com Wed Apr 8 13:03:16 2009 From: rbgarga at gmail.com (Renato Botelho) Date: Wed Apr 8 13:03:23 2009 Subject: new usb: mass storage error, Synchronize cache failed In-Reply-To: <200904082049.09103.hselasky@c2i.net> References: <747dc8f30904071139j32b55e2pf0fcd07a51c260a2@mail.gmail.com> <200904082033.30722.hselasky@c2i.net> <747dc8f30904081142r704bb155q8fc8bbb37a30322f@mail.gmail.com> <200904082049.09103.hselasky@c2i.net> Message-ID: <747dc8f30904081302j468eb310pb6e80702155810a7@mail.gmail.com> On Wed, Apr 8, 2009 at 3:49 PM, Hans Petter Selasky wrote: > On Wednesday 08 April 2009, Renato Botelho wrote: >> On Wed, Apr 8, 2009 at 3:33 PM, Hans Petter Selasky > wrote: > >> Since I was on old-than-my-src version, I rebuilt >> world and kernel with r190843 > > And what is the dmesg after patching? I couldn't find any difference ugen1.2: at usbus1 umass0: on usbus1 umass0: SCSI over Bulk-Only; quirks = 0x0000 umass0:0:0:-1: Attached to scbus0 da0 at umass-sim0 bus 0 target 0 lun 0 da0: Removable Direct Access SCSI-0 device da0: 1.000MB/s transfers da0: 982MB (2012160 512 byte sectors: 64H 32S/T 982C) da1 at umass-sim0 bus 0 target 0 lun 1 da1: Removable Direct Access SCSI-0 device da1: 1.000MB/s transfers da1: 1MB (3668 512 byte sectors: 64H 32S/T 1C) GEOM: da0: partition 1 does not start on a track boundary. GEOM: da0: partition 1 does not end on a track boundary. ugen1.2: at usbus1 (disconnected) umass0: at uhub1, port 1, addr 2 (disconnected) (da1:umass-sim0:0:0:1): Synchronize cache failed, status == 0x3f, scsi status == 0x0 (da0:umass-sim0:0:0:0): lost device (da0:umass-sim0:0:0:0): removing device entry (da1:umass-sim0:0:0:1): lost device (da1:umass-sim0:0:0:1): removing device entry -- Renato Botelho From ndenev at gmail.com Wed Apr 8 13:33:28 2009 From: ndenev at gmail.com (Niki Denev) Date: Wed Apr 8 13:33:35 2009 Subject: axe(4) (Belkin F5D5055) problems In-Reply-To: <3a142e750904080113s484b6c7emb2ad0caf85f320b4@mail.gmail.com> References: <75656435-49E2-457A-9CFE-8706CD44916E@gmail.com> <2e77fc10903280942u7c934aa4w80176680e9dff6d7@mail.gmail.com> <2e77fc10903281539h7b713711w116a90fd2bfadbcf@mail.gmail.com> <20090330021648.GE7076@michelle.cdnetworks.co.kr> <20090330024748.GF7076@michelle.cdnetworks.co.kr> <2e77fc10904071315q66d725bl76229d9bffd92f35@mail.gmail.com> <20090408024901.GC37714@michelle.cdnetworks.co.kr> <2e77fc10904072345o4d8215dcg561931ede528bcd6@mail.gmail.com> <3a142e750904080113s484b6c7emb2ad0caf85f320b4@mail.gmail.com> Message-ID: <2e77fc10904081333h4f658dc7sa156bd9d4f957a54@mail.gmail.com> On Wed, Apr 8, 2009 at 11:13 AM, Paul B. Mahol wrote: > > Please tell me what functions? > Or provide link to driver you used. > > -- > Paul > It was sometime ago, and I couldn't remember the details correctly, so I've tried again with the latest driver from http://www.sis.com/download version 2.07 And when I loaded the module the message was : no match for ExInterlockedInsertHeadList and then panic. Thanks, Niki From kientzle at freebsd.org Wed Apr 8 13:34:34 2009 From: kientzle at freebsd.org (Tim Kientzle) Date: Wed Apr 8 13:34:50 2009 Subject: firefox3 with high latencies when acting with mouse or keyboard and graphics refresh In-Reply-To: <49DCA9E0.6000109@zedat.fu-berlin.de> References: <49DCA9E0.6000109@zedat.fu-berlin.de> Message-ID: <49DD0A57.7020701@freebsd.org> I saw something similar recently due to a mismatch between hald and the xorg server. In my case, it affected all applications, not just firefox. * Are you running hald? * Do you have "AllowEmptyInput" set in /etc/X11/xorg.conf? * Are you starting xdm, kdm, or gdm from /etc/ttys? Tim O. Hartmann wrote: > Hello, > got a problem since yesterday after having done a lot of updates > (ports): on all of my FreeBSD 8.0-CURRENT/amd64 boxes firefox does have > enormous high latencies when typing in or moving the mouse or popping up > the window icon or down. Since this happens on all of 8.0-CUR/amd boxes, > I guess it has something to do with an upgrade of the ports. > > I reinstalled firefox twice, but without success, so I want to ask for > some hints.. > > Regards, > Oliver > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > > From hselasky at c2i.net Wed Apr 8 13:44:51 2009 From: hselasky at c2i.net (Hans Petter Selasky) Date: Wed Apr 8 13:44:58 2009 Subject: new usb: mass storage error, Synchronize cache failed In-Reply-To: <747dc8f30904081302j468eb310pb6e80702155810a7@mail.gmail.com> References: <747dc8f30904071139j32b55e2pf0fcd07a51c260a2@mail.gmail.com> <200904082049.09103.hselasky@c2i.net> <747dc8f30904081302j468eb310pb6e80702155810a7@mail.gmail.com> Message-ID: <200904082247.18866.hselasky@c2i.net> On Wednesday 08 April 2009, Renato Botelho wrote: > umass0: ?SCSI over Bulk-Only; quirks = 0x0000 umass0: SCSI over Bulk-Only; quirks = 0x0000 If the quirks print is still zero, then your patch is not correct, or you have not recompiled and installed the patched files! --HPS From hartzell at alerce.com Wed Apr 8 14:20:08 2009 From: hartzell at alerce.com (George Hartzell) Date: Wed Apr 8 14:26:26 2009 Subject: "zfs send -R data@now | zfs receive -vdF backups" odd behaviour Message-ID: [ I thought I sent this back in early March, but I never heard anything and don't see in the archives, so I'm hoping that I dropped the ball. ] I have a -CURRENT system csup'ed last night, with the small patch from PR bin/130105 so that 'zfs send -R' works. My system has two disks in a mirrored pool named data. The disks are both partitioned using GPT (freebsd-boot, freebsd-swap, freebsd-zfs) and use gptzfsboot. I also have a third disk that is partitioned as above. If I create a new zpool on that third disk named backups, take a recursive snapshot of data and then send the filesystems stored on data to backups, I end up with *one* filesystem mounted twice. In other words, after doing the send and receive, /home has been mounted from data/home and then also mounted from backups/home. I'm confused about two points: - all of the filesystems on data seem to have all of the same attributes set, yet only data@home ends up mounted. - why does anything from backups end up mounted? Is the behavious I'm seeing to be expected? I've attached a script below Script started on Sat Mar 7 13:38:31 2009 > zpool list NAME SIZE USED AVAIL CAP HEALTH ALTROOT data 276G 5.74G 271G 2% ONLINE - > sudo zpool create backups ad13p3 Password: > zpool list NAME SIZE USED AVAIL CAP HEALTH ALTROOT backups 90.5G 73.5K 90.5G 0% ONLINE - data 276G 5.74G 271G 2% ONLINE - > sudo zfs destroy -r data@now > sudo zfs snapshot -r data@now > df Filesystem 1K-blocks Used Avail Capacity Mounted on data 279913472 530944 279382528 0% / devfs 1 1 0 100% /dev data/home 279382528 0 279382528 0% /home data/tmp 279382528 0 279382528 0% /tmp data/usr 284771072 5388544 279382528 2% /usr data/var 279478912 96384 279382528 0% /var backups 93413248 0 93413248 0% /backups > sudo zfs send -R data@now | sudo zfs receive -vdF backups receiving full stream of data@now into backups@now received 521MB stream in 29 seconds (18.0MB/sec) receiving full stream of data/home@now into backups/home@now received 40.0KB stream in 1 seconds (40.0KB/sec) receiving full stream of data/usr@now into backups/usr@now received 5.34GB stream in 338 seconds (16.2MB/sec) receiving full stream of data/var@now into backups/var@now received 112MB stream in 14 seconds (8.02MB/sec) receiving full stream of data/tmp@now into backups/tmp@now received 99.7KB stream in 1 seconds (99.7KB/sec) > df Filesystem 1K-blocks Used Avail Capacity Mounted on data 279912960 530944 279382016 0% / devfs 1 1 0 100% /dev data/home 279382016 0 279382016 0% /home data/tmp 279382016 0 279382016 0% /tmp data/usr 284770560 5388544 279382016 2% /usr data/var 279478400 96384 279382016 0% /var backups/home 87396864 0 87396864 0% /home > sudo umount /home Password: > df Filesystem 1K-blocks Used Avail Capacity Mounted on data 279912960 530944 279382016 0% / devfs 1 1 0 100% /dev data/home 279382016 0 279382016 0% /home data/tmp 279382016 0 279382016 0% /tmp data/usr 284770560 5388544 279382016 2% /usr data/var 279478400 96384 279382016 0% /var > ^Dexit Script done on Sat Mar 7 13:48:15 2009 From rysto32 at gmail.com Wed Apr 8 15:20:58 2009 From: rysto32 at gmail.com (Ryan Stone) Date: Wed Apr 8 15:21:07 2009 Subject: NFS lockd/statd lock up network connection In-Reply-To: References: <49D851FC.4090103@sdf.lonestar.org> Message-ID: Forgot to reply all, sorry. ---------- Forwarded message ---------- From: Ryan Stone Date: Wed, Apr 8, 2009 at 6:12 PM Subject: Re: NFS lockd/statd lock up network connection To: Tom McLaughlin On Wed, Apr 8, 2009 at 6:05 PM, Ryan Stone wrote: > > em0: Could not setup receive structures > > The em driver prints this out when it can't allocate mbufs or clusters. > Can you show the output of vmstat -z? This error is indicative of a leak of > mbufs or clusters, or a misconfiguration(too few mbufs or clusters). > > Ryan Stone > Also, can you run sysctl dev.em.0.debug=1? That will print a bunch of debugging information to the console. The two lines I'm most interested in are Std mbuf failed = Std mbuf cluster failed = From rysto32 at gmail.com Wed Apr 8 15:29:06 2009 From: rysto32 at gmail.com (Ryan Stone) Date: Wed Apr 8 15:29:13 2009 Subject: NFS lockd/statd lock up network connection In-Reply-To: <49D851FC.4090103@sdf.lonestar.org> References: <49D851FC.4090103@sdf.lonestar.org> Message-ID: > em0: Could not setup receive structures The em driver prints this out when it can't allocate mbufs or clusters. Can you show the output of vmstat -z? This error is indicative of a leak of mbufs or clusters, or a misconfiguration(too few mbufs or clusters). Ryan Stone From pyunyh at gmail.com Wed Apr 8 18:08:49 2009 From: pyunyh at gmail.com (Pyun YongHyeon) Date: Wed Apr 8 18:08:59 2009 Subject: axe(4) (Belkin F5D5055) problems In-Reply-To: <2e77fc10904072345o4d8215dcg561931ede528bcd6@mail.gmail.com> References: <2e77fc10903280259s5a761cacs398b88649a2367fe@mail.gmail.com> <20090328102735.GE99923@michelle.cdnetworks.co.kr> <2e77fc10903280942u7c934aa4w80176680e9dff6d7@mail.gmail.com> <2e77fc10903281539h7b713711w116a90fd2bfadbcf@mail.gmail.com> <20090330021648.GE7076@michelle.cdnetworks.co.kr> <20090330024748.GF7076@michelle.cdnetworks.co.kr> <2e77fc10904071315q66d725bl76229d9bffd92f35@mail.gmail.com> <20090408024901.GC37714@michelle.cdnetworks.co.kr> <2e77fc10904072345o4d8215dcg561931ede528bcd6@mail.gmail.com> Message-ID: <20090409010953.GE37714@michelle.cdnetworks.co.kr> On Wed, Apr 08, 2009 at 09:45:26AM +0300, Niki Denev wrote: > Hi Pyun, > > On Wed, Apr 8, 2009 at 5:49 AM, Pyun YongHyeon wrote: > > On Tue, Apr 07, 2009 at 11:15:47PM +0300, Niki Denev wrote: > > > > [...] > > > > I've read the datasheet but I still don't understand why dsp > > programming in truephy_reset is required. Anyway would you try > > attached patch? And show me dmesg output generated by truephy(4). > > Here is the dmesg output with the latest patch. > > truephy0: PHY 1 on miibus0 > truephy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, > 1000baseT-FDX, auto > > > > > >> I have temporarily replaced the belkin USB ethernet interface with an > >> Apple USB ethernet, > >> which also uses the axe(4) driver, but is only 100Mbit/s. > >> As I suspected the negotiation problems do not exist with it, and > >> everything seemed ok, until > >> it started to stop working exactly like the previous adapter. > >> Pings start to return "buffer space not available" and replugging or > >> "usbconfig reset" the interface > >> returns it to normal status. > >> > > > > This sounds like different issue to me. Let's focus on the > > truephy(4) until axe(4) get a valid link report. > > > > Ok. > With this patch the old problems still persist. > Can you add a couple of printf()s in if_axe.c:axe_miibus_statchg and see how link state/speed reports are generated? Does it cycle between 1000baseT-FDX and 100baseTX-HDX? And the UTP cable you used was proven to work without problems with gigabit link? It seems ET1011C performs automatic-downshifting so I'd like to rule out it. > >> It looks like that the packet loss that I've experienced with the > >> Belkin gigabit adabter is one problem, > >> and the interface stopping to work another. > >> > >> P.S.: I don't know if it could be my USB hardware, because the machine > >> is a little bit "exotic", > >> an HP ex470 MediaSmartServer, which was supposedly designed to run > >> only embedded version of > >> Windows and has a nasty SiS chipset in it (with the unsupported sis191 > >> gigabit adapter) > > > > There had been a post for SiS191 driver. Check mailing list > > archives. Unfortunately I don't have SiS191 controller so I > > couldn't write a driver and commit the posted driver to tree. > > Even though the controller is not for high performance servers it > > would be enough to most desktop users. At least SiS controllers > > does not seem to require special workarounds for silicon bugs which > > are commonly found on RealTek/Marvell controllers. > > > > Yes, I've tried to make this driver work for several days, I've found > OpenSolaris driver and tried to get some stuff missing in the linux > driver from it, > but the best I got was to see some packets on the wire, but was never > able to send anything. It's hard to say what was broken here but it seems SiS190 has severe hardware limitation(no hardware padding, no multi dma segment support, etc) You may use similar code of if_rl.c:rl_encap() or if_vr.c:vr_encap(). > Also the SiS191 seems to have problems negotiating gigabit link, there > are many posts about this > when using Linux. > This could be related with PHY handling bug of Linux sis190 driver. Because Linux does not have mii(4) it have to poke PHY registers in driver layer which in turn would make it hard to support various PHY hardwares. > > Alternatively you can use ndis(4) to use your SiS191 controller. I > > don't know whether ndis(4) works for this controller though. > > > > I've tried, but afair there were some functions in the driver that > were not yet implemented > in the ndis layer, so it didn't worked for me. > Make sure you've used NDIS 5.0 compliant driver. ndis(4) does not support NDIS 6.0 yet. From ndenev at gmail.com Wed Apr 8 23:34:14 2009 From: ndenev at gmail.com (Niki Denev) Date: Wed Apr 8 23:34:21 2009 Subject: axe(4) (Belkin F5D5055) problems In-Reply-To: <20090409010953.GE37714@michelle.cdnetworks.co.kr> References: <2e77fc10903280259s5a761cacs398b88649a2367fe@mail.gmail.com> <2e77fc10903280942u7c934aa4w80176680e9dff6d7@mail.gmail.com> <2e77fc10903281539h7b713711w116a90fd2bfadbcf@mail.gmail.com> <20090330021648.GE7076@michelle.cdnetworks.co.kr> <20090330024748.GF7076@michelle.cdnetworks.co.kr> <2e77fc10904071315q66d725bl76229d9bffd92f35@mail.gmail.com> <20090408024901.GC37714@michelle.cdnetworks.co.kr> <2e77fc10904072345o4d8215dcg561931ede528bcd6@mail.gmail.com> <20090409010953.GE37714@michelle.cdnetworks.co.kr> Message-ID: <2e77fc10904082334v3fc9676cy97ad97f4e7fe6d0a@mail.gmail.com> On Thu, Apr 9, 2009 at 4:09 AM, Pyun YongHyeon wrote: > On Wed, Apr 08, 2009 at 09:45:26AM +0300, Niki Denev wrote: >> Hi Pyun, >> >> On Wed, Apr 8, 2009 at 5:49 AM, Pyun YongHyeon wrote: >> > On Tue, Apr 07, 2009 at 11:15:47PM +0300, Niki Denev wrote: >> > >> > [...] >> > >> > I've read the datasheet but I still don't understand why dsp >> > programming in truephy_reset is required. Anyway would you try >> > attached patch? And show me dmesg output generated by truephy(4). >> >> Here is the dmesg output with the latest patch. >> >> truephy0: PHY 1 on miibus0 >> truephy0: ?10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, >> 1000baseT-FDX, auto >> >> >> > >> >> I have temporarily replaced the belkin USB ethernet interface with an >> >> Apple USB ethernet, >> >> which also uses the axe(4) driver, but is only 100Mbit/s. >> >> As I suspected the negotiation problems do not exist with it, and >> >> everything seemed ok, until >> >> it started to stop working exactly like the previous adapter. >> >> Pings start to return "buffer space not available" and replugging or >> >> "usbconfig reset" the interface >> >> returns it to normal status. >> >> >> > >> > This sounds like different issue to me. Let's focus on the >> > truephy(4) until axe(4) get a valid link report. >> > >> >> Ok. >> With this patch the old problems still persist. >> > > Can you add a couple of printf()s in if_axe.c:axe_miibus_statchg > and see how link state/speed reports are generated? Does it > cycle between 1000baseT-FDX and 100baseTX-HDX? > And the UTP cable you used was proven to work without problems with > gigabit link? It seems ET1011C performs automatic-downshifting so > I'd like to rule out it. > There are two switch statements in axe_miibus_statchg, and I've put printfs in each case in both of them, and the results is and in each call it matches once the two cases for 1000T and then, 100T and it repeats. I guess this means it cycles between 1000baseT-FXD and 100baseTX-FDX? As for the cables, I've also suspected this, and tried several Cat 5e cables, and right now I'm testing with Cat 6 cable which works with other gige hardware without problems. Also I've tried different switch ports on the ProCurve 1800-8G >> >> It looks like that the packet loss that I've experienced with the >> >> Belkin gigabit adabter is one problem, >> >> and the interface stopping to work another. >> >> >> >> P.S.: I don't know if it could be my USB hardware, because the machine >> >> is a little bit "exotic", >> >> an HP ex470 MediaSmartServer, which was supposedly designed to run >> >> only embedded version of >> >> Windows and has a nasty SiS chipset in it (with the unsupported sis191 >> >> gigabit adapter) >> > >> > There had been a post for SiS191 driver. Check mailing list >> > archives. Unfortunately I don't have SiS191 controller so I >> > couldn't write a driver and commit the posted driver to tree. >> > Even though the controller is not for high performance servers it >> > would be enough to most desktop users. At least SiS controllers >> > does not seem to require special workarounds for silicon bugs which >> > are commonly found on RealTek/Marvell controllers. >> > >> >> Yes, I've tried to make this driver work for several days, I've found >> OpenSolaris driver and tried to get some stuff missing in the linux >> driver from it, >> but the best I got was to see some packets on the wire, but was never >> able to send anything. > > It's hard to say what was broken here but it seems SiS190 has > severe hardware limitation(no hardware padding, no multi dma segment > support, etc) You may use similar code of if_rl.c:rl_encap() or > if_vr.c:vr_encap(). > Thanks, I'll see if I can make it work. >> Also the SiS191 seems to have problems negotiating gigabit link, there >> are many posts about this >> when using Linux. >> > > This could be related with PHY handling bug of Linux sis190 driver. > Because Linux does not have mii(4) it have to poke PHY registers in > driver layer which ?in turn would make it hard to support various > PHY hardwares. > I've noticed this. The linux drives seems to write some magic numbers to the hardware at several places... very confusing. >> > Alternatively you can use ndis(4) to use your SiS191 controller. I >> > don't know whether ndis(4) works for this controller though. >> > >> >> I've tried, but afair there were some functions in the driver that >> were not yet implemented >> in the ndis layer, so it didn't worked for me. >> > > Make sure you've used NDIS 5.0 compliant driver. ndis(4) does not > support NDIS 6.0 yet. > All of the drivers I've tested (and I could find for this chip) seem to be NDIS 5.1 (at least thats what is written in the .inf file) Many thanks, Niki From rmtodd at ichotolot.servalan.com Thu Apr 9 00:23:36 2009 From: rmtodd at ichotolot.servalan.com (Richard Todd) Date: Thu Apr 9 00:23:44 2009 Subject: ATA related panic during ZFS scrub In-Reply-To: (Mark Powell's message of "Wed, 8 Apr 2009 17:36:17 +0100 (BST)") References: <20090408170231.K38445@rust.salford.ac.uk> Message-ID: "Mark Powell" writes: > Hi, > Got a panic I'd not seen before, yesterday, whilst scrubbing one of > two pools, to fix the apparently spurious CRC errors highlighted here: > > http://kerneltrap.org/mailarchive/freebsd-current/2009/4/7/5428764 [...] > Sorry, but I don't have a serial console or dump device valid in a > panic. Here are screenshots: > > http://www.rootshell.be/~msp/IMG_4393.JPG > > Here's the edited gocr of the above: > > ----- > Fatal trap 9 general protection fault while in kernel mode > cpuid -- 1; apic id = 01 > instruction pointer = Ox8:Oxffffffff807db306 > stack pointer = Ox10:OxfffffffeeS79faaO > frame pointer = 0x10:Oxfffffffee579faeO > Code Segment = base Ox0, limit Oxfffff, type Ox1b > = DPL 0, pres 1, long 1, def32 0, gran 1 > processor eflags = interrupt enabled, resume, IOPL O > current process = 12 (irq19: atacpi1++) > [thread pid 12 tid 100032 ] > Stopped at bcopy+Ox16 repe movsq (%rsi),%es:(%rdi) Hmm, interesting, I got a panic, also apparently somewhere in the bounce buffer code: Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address = 0x26bffcea9f0 fault code = supervisor read data, page not present instruction pointer = 0x8:0xffffffff807f4b29 stack pointer = 0x10:0xfffffffe40049980 frame pointer = 0x10:0xfffffffe400499c0 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 4 (g_down) [thread pid 4 tid 100011 ] Stopped at add_bounce_page+0x99: movq 0x20(%rbx),%rax db> lock order reversal: (Giant after non-sleepable) 1st 0xffffffff80da4ac0 bounce pages lock (bounce pages lock) @ /usr/src/sys/amd64/amd64/busdma_machdep.c:1126 2nd 0xffffffff80bcf540 Giant (Giant) @ /usr/src/sys/dev/kbdmux/kbdmux.c:1044 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2a _witness_debugger() at _witness_debugger+0x2e witness_checkorder() at witness_checkorder+0x81e _mtx_lock_flags() at _mtx_lock_flags+0x78 kbdmux_ioctl() at kbdmux_ioctl+0x116 sc_cngetc() at sc_cngetc+0xcb cncheckc() at cncheckc+0x65 cngetc() at cngetc+0x1c db_readline() at db_readline+0x77 db_read_line() at db_read_line+0x15 db_command_loop() at db_command_loop+0x38 db_trap() at db_trap+0x89 kdb_trap() at kdb_trap+0x95 trap_fatal() at trap_fatal+0x2bd trap() at trap+0x2a5 calltrap() at calltrap+0x8 --- trap 0xc, rip = 0xffffffff807f4b29, rsp = 0xfffffffe40049980, rbp = 0xfffffffe400499c0 --- add_bounce_page() at add_bounce_page+0x99 bus_dmamap_load() at bus_dmamap_load+0x256 ata_dmaload() at ata_dmaload+0x12c ata_ahci_begin_transaction() at ata_ahci_begin_transaction+0x1fe ata_start() at ata_start+0x1c5 ata_queue_request() at ata_queue_request+0x12c g_disk_start() at g_disk_start+0xf4 g_io_schedule_down() at g_io_schedule_down+0x1e4 g_down_procbody() at g_down_procbody+0x6f fork_exit() at fork_exit+0x12a fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xfffffffe40049d30, rbp = 0 --- Note that, as others have noted in this thread, the "lock order reversal" business is all stuff that happens after the system dropped into the debugger; the actual panic is one that happens in the bounce buffer code, in add_bounce_page. I tried to get a core dump, but alas, no go: db> call doadump Physical memory: 4012 MB Dumping 1991 MB:lock order reversal: 1st 0xfffffffe405e89a8 ATA queue lock (ATA queue lock) @ /usr/src/sys/dev/ata/ata-queue.c:184 2nd 0xffffffff80da4ac0 bounce pages lock (bounce pages lock) @ /usr/src/sys/amd64/amd64/busdma_machdep.c:1126 3rd 0xfffffffe406109a8 ATA queue lock (ATA queue lock) @ /usr/src/sys/dev/ata/ata-queue.c:86 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2a _witness_debugger() at _witness_debugger+0x2e witness_checkorder() at witness_checkorder+0x81e _mtx_lock_flags() at _mtx_lock_flags+0x78 ata_queue_request() at ata_queue_request+0xae ad_dump() at ad_dump+0xaf minidumpsys() at minidumpsys+0x3e3 dumpsys() at dumpsys+0x2e doadump() at doadump+0x49 db_fncall() at db_fncall+0x8c db_command() at db_command+0x201 db_command_loop() at db_command_loop+0x50 db_trap() at db_trap+0x89 kdb_trap() at kdb_trap+0x95 trap_fatal() at trap_fatal+0x2bd trap() at trap+0x2a5 calltrap() at calltrap+0x8 --- trap 0xc, rip = 0xffffffff807f4b29, rsp = 0xfffffffe40049980, rbp = 0xfffffffe400499c0 --- add_bounce_page() at add_bounce_page+0x99 bus_dmamap_load() at bus_dmamap_load+0x256 ata_dmaload() at ata_dmaload+0x12c ata_ahci_begin_transaction() at ata_ahci_begin_transaction+0x1fe ata_start() at ata_start+0x1c5 ata_queue_request() at ata_queue_request+0x12c g_disk_start() at g_disk_start+0xf4 g_io_schedule_down() at g_io_schedule_down+0x1e4 g_down_procbody() at g_down_procbody+0x6f fork_exit() at fork_exit+0x12a fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xfffffffe40049d30, rbp = 0 --- 1976 1960 1944 1928 1912 1896 1880 1864 1848 1832 1816 1800 1784 1768 1752 1736 1720 1704 1688 1672 1656 1640 1624 1608 1592 1576 1560 1544 1528 1512 1496 1480 1464 1448 1432 1416 1400 1384 1368 1352 1336 1320 1304 1288 1272 1256 1240 1224 1208 1192 1176 1160 1144 1128 1112 1096 1080 1064 1048 1032 1016 1000 984 968 952 936 920 904 888 872 856 840 824 808 792 776 760 744 728 712 696 680 664 648 632 616 600 584 568 552 536 520 504 488 472 456 440 424 408 392 376 360 344 328 312 296 280 264 248 232 216 200 184 168 152 136 120 104 88 72 56 40 24 8Attempt to write outside dump device boundaries. ** DUMP FAILED (ERROR 6) ** = 0 db> reset (And yes, the dump device *does* have adequate room for 4G or more of dump, and dumps have worked on other occasions.) I guess it's not too surprising that if something in the bounce buffers and/or disk IO system is confused that you might not be able to get a good dump, but it's still fairly annoying. > Someone suggested that this and/or the problems, in the other thread > above, could be related to a bug in bounce buffers which occurs quite > rarely, but is causing writing the wrong blocks or data? (Just for the record, "someone" is me, in an offlist exchange I had with Mark Powell.) From M.S.Powell at salford.ac.uk Thu Apr 9 02:48:47 2009 From: M.S.Powell at salford.ac.uk (Mark Powell) Date: Thu Apr 9 02:48:54 2009 Subject: kbdmux vs ATA? (was: ATA related panic during ZFS scrub) In-Reply-To: References: <20090408170231.K38445@rust.salford.ac.uk> Message-ID: <20090409104451.D38445@rust.salford.ac.uk> On Wed, 8 Apr 2009, Ivan Voras wrote: > Hmmm, this shows a lock order problem between ATA and kbdmux's Giant. Ooops. It seems I flunked my 'reading panics' class :( >> / is ufs on USB key > > Are you saying the system has only USB drives or that the ZFS pool was > on the USB drive (or something else)? > > In any case, USB drives do not appear as ATA drives. Sorry. I wasn't clear. I mentioned the usb key, as I've seen other threads reporting zfs corruption with usb. / ufs on usb key Everything else except / is on SATA: /pool raidz1 4x500gb+500gb stripe of 2xSATA drives /pool2 raidz2 6x1tb Cheers. -- Mark Powell - UNIX System Administrator - The University of Salford Information & Learning Services, Clifford Whitworth Building, Salford University, Manchester, M5 4WT, UK. Tel: +44 161 295 6843 Fax: +44 161 295 5888 www.pgp.com for PGP key From ohartman at zedat.fu-berlin.de Thu Apr 9 04:19:56 2009 From: ohartman at zedat.fu-berlin.de (O. Hartmann) Date: Thu Apr 9 04:20:02 2009 Subject: firefox3 with high latencies when acting with mouse or keyboard and graphics refresh In-Reply-To: <20090408173319.GA2370@free.bsd.loc> References: <49DCA9E0.6000109@zedat.fu-berlin.de> <20090408173319.GA2370@free.bsd.loc> Message-ID: <49DDD984.8000104@zedat.fu-berlin.de> Jeff Laine wrote: > On Wed, Apr 08, 2009 at 01:42:56PM +0000, O. Hartmann wrote: >> Hello, >> got a problem since yesterday after having done a lot of updates >> (ports): on all of my FreeBSD 8.0-CURRENT/amd64 boxes firefox does have >> enormous high latencies when typing in or moving the mouse or popping up >> the window icon or down. Since this happens on all of 8.0-CUR/amd boxes, >> I guess it has something to do with an upgrade of the ports. >> >> I reinstalled firefox twice, but without success, so I want to ask for >> some hints.. >> >> Regards, >> Oliver > > > It is unlikely your case, but I've had similar issues with firefox on my laptop > with intel video under 7.2-PRERELEASE. > Setting video driver option "AccelMethod" to old XAA mode in xorg.conf helped a lot. > > > > It is NOT the way I try Acceleration or not or what driver the box uses, this happens with VESA, Radeon, RadeonHD as well. VESA worked before. This is only on FreeBSD 8.0/amd64 with local displays. starting firefox3 remotely, this problem does not occur. I guess due to a lot of updates in xorg-port there is again an issue. The never ending story with X11 and wicked updates. From rbgarga at gmail.com Thu Apr 9 04:32:01 2009 From: rbgarga at gmail.com (Renato Botelho) Date: Thu Apr 9 04:32:07 2009 Subject: new usb: mass storage error, Synchronize cache failed In-Reply-To: <200904082247.18866.hselasky@c2i.net> References: <747dc8f30904071139j32b55e2pf0fcd07a51c260a2@mail.gmail.com> <200904082049.09103.hselasky@c2i.net> <747dc8f30904081302j468eb310pb6e80702155810a7@mail.gmail.com> <200904082247.18866.hselasky@c2i.net> Message-ID: <747dc8f30904090431nc7c8b4cx5be4a5f4023af2af@mail.gmail.com> On Wed, Apr 8, 2009 at 5:47 PM, Hans Petter Selasky wrote: > On Wednesday 08 April 2009, Renato Botelho wrote: >> umass0: ?SCSI over Bulk-Only; quirks = 0x0000 > > > umass0: ?SCSI over Bulk-Only; quirks = 0x0000 > > If the quirks print is still zero, then your patch is not correct, or you have > not recompiled and installed the patched files! Sorry, my fault, I made a mistake on product ID, but it still doesn't work, here is the new dmesg: ugen1.2: at usbus1 umass0: on usbus1 umass0: SCSI over Bulk-Only; quirks = 0x4000 umass0:0:0:-1: Attached to scbus0 da0 at umass-sim0 bus 0 target 0 lun 0 da0: Removable Direct Access SCSI-0 device da0: 1.000MB/s transfers da0: 982MB (2012160 512 byte sectors: 64H 32S/T 982C) da1 at umass-sim0 bus 0 target 0 lun 1 da1: Removable Direct Access SCSI-0 device da1: 1.000MB/s transfers da1: 1MB (3668 512 byte sectors: 64H 32S/T 1C) GEOM: da0: partition 1 does not start on a track boundary. GEOM: da0: partition 1 does not end on a track boundary. ugen1.2: at usbus1 (disconnected) umass0: at uhub1, port 1, addr 2 (disconnected) (da1:umass-sim0:0:0:1): Synchronize cache failed, status == 0x3f, scsi status == 0x0 (da0:umass-sim0:0:0:0): lost device (da0:umass-sim0:0:0:0): removing device entry (da1:umass-sim0:0:0:1): lost device (da1:umass-sim0:0:0:1): removing device entry -- Renato Botelho From hselasky at c2i.net Thu Apr 9 05:43:40 2009 From: hselasky at c2i.net (Hans Petter Selasky) Date: Thu Apr 9 05:43:47 2009 Subject: new usb: mass storage error, Synchronize cache failed In-Reply-To: <747dc8f30904090431nc7c8b4cx5be4a5f4023af2af@mail.gmail.com> References: <747dc8f30904071139j32b55e2pf0fcd07a51c260a2@mail.gmail.com> <200904082247.18866.hselasky@c2i.net> <747dc8f30904090431nc7c8b4cx5be4a5f4023af2af@mail.gmail.com> Message-ID: <200904091446.08486.hselasky@c2i.net> On Thursday 09 April 2009, Renato Botelho wrote: > On Wed, Apr 8, 2009 at 5:47 PM, Hans Petter Selasky wrote: > > On Wednesday 08 April 2009, Renato Botelho wrote: > >> umass0: ?SCSI over Bulk-Only; quirks = 0x0000 > > > > umass0: ?SCSI over Bulk-Only; quirks = 0x0000 > > > > If the quirks print is still zero, then your patch is not correct, or you > > have not recompiled and installed the patched files! > > Sorry, my fault, I made a mistake on product ID, but it still doesn't > work, here is the new dmesg: > > ugen1.2: at usbus1 > umass0: on usbus1 > umass0: SCSI over Bulk-Only; quirks = 0x4000 > umass0:0:0:-1: Attached to scbus0 > da0 at umass-sim0 bus 0 target 0 lun 0 > da0: Removable Direct Access SCSI-0 device > da0: 1.000MB/s transfers > da0: 982MB (2012160 512 byte sectors: 64H 32S/T 982C) > da1 at umass-sim0 bus 0 target 0 lun 1 > da1: Removable Direct Access SCSI-0 device > da1: 1.000MB/s transfers > da1: 1MB (3668 512 byte sectors: 64H 32S/T 1C) > GEOM: da0: partition 1 does not start on a track boundary. > GEOM: da0: partition 1 does not end on a track boundary. > ugen1.2: at usbus1 (disconnected) > umass0: at uhub1, port 1, addr 2 (disconnected) > (da1:umass-sim0:0:0:1): Synchronize cache failed, status == 0x3f, scsi > status == 0x0 > (da0:umass-sim0:0:0:0): lost device > (da0:umass-sim0:0:0:0): removing device entry > (da1:umass-sim0:0:0:1): lost device > (da1:umass-sim0:0:0:1): removing device entry Try adding more of the possible quirks. --HPS From dumbbell at FreeBSD.org Thu Apr 9 07:01:44 2009 From: dumbbell at FreeBSD.org (=?UTF-8?B?SmVhbi1Tw6liYXN0aWVuIFDDqWRyb24=?=) Date: Thu Apr 9 07:01:51 2009 Subject: New ioctl to support Enhanced CD (or Extra CD) Message-ID: <49DDF942.9040808@FreeBSD.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello, Enhanced CD (or Extra CA) is an Audio CD with an additionnal data track at the end. Audio tracks belong to the first session while the data track belongs to the second session. Therefore the last audio track ends way before the data track start. The first consequence is that the duration of the last audio track isn't reported correctly. Here is the output of cdcontrol(1) with such a CD[1]: $ cdcontrol info ... 12 46:03.67 9:54.43 207142 44593 audio 13 55:58.35 6:38.51 251735 29901 data The expected output is: $ cdcontrol info ... 12 46:03.67 7:22.43 207142 33193 audio 13 55:58.35 6:38.51 251735 29901 data A more "audible" consequence is that cdparanoia(1) copies 9'54" of data instead of 7'22". The end of the ripped file is full of garbage. I made a patch (attached) that adds a new ioctl to query the start address of the last session. This new ioctl is named CDIOREADLASTSESSIONADDR. The patch also includes changes to cdcontrol(1). I added a new member at the end of struct acd_softc to store the last session address. I don't know if this causes ABI breakage. Linux' corresponding ioctl is CDROMMULTISESSION. Beside this address, it returns a flag named "xa_flag". Currently, I don't understand what it is but it may be useful to add it to our ioctl too if someone knows its purpose. Before I spend some time to teach cdparanoia(1) about this new ioctl, I'd like some feedback on this patch, especially the name and the struct ioc_read_last_session_addr. I would appreciate some test reports too! :) [1] This was tested with Avishai Cohen's last album, "Aurora". - -- Jean-S?bastien P?dron http://www.dumbbell.fr/ PGP Key: http://www.dumbbell.fr/pgp/pubkey.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAknd+UIACgkQa+xGJsFYOlNzCgCeNz3PEoL7nqSsc1mMcKOBAYag MUUAoIFVuhZ9lEPsvI17V3tRYCeOjvDM =pUJY -----END PGP SIGNATURE----- -------------- next part -------------- Index: usr.sbin/cdcontrol/cdcontrol.c =================================================================== --- usr.sbin/cdcontrol/cdcontrol.c (revision 190463) +++ usr.sbin/cdcontrol/cdcontrol.c (working copy) @@ -120,6 +120,7 @@ }; struct cd_toc_entry toc_buffer[100]; +union msf_lba last_session_addr; const char *cdname; int fd = -1; @@ -1021,6 +1022,36 @@ e[1].addr.msf.frame); else next = ntohl(e[1].addr.lba); + + if (!(e->control & 4) && e[1].control & 4) { + int end_lba; + + /* + * The current track is an audio track and the next one is + * a data track: this is an Enhanced CD (or Extra CD). In + * this case, the current track ends way before the data + * track. We must consider the last_session_addr instead. + */ + + if (last_session_addr.lba != 0) { + if (msf) { + end_lba = msf2lba(last_session_addr.msf.minute, + last_session_addr.msf.second, + last_session_addr.msf.frame); + } else { + end_lba = last_session_addr.lba; + } + end_lba -= (90 + 60 + 2) * 75; + + if (end_lba >= block && end_lba < next) + next = end_lba; + } else { + warnx("couldn't query sessions informations; " + "last audio track\neffective duration " + "may be shorter than the reported duration!"); + } + } + len = next - block; /* Take into account a start offset time. */ lba2msf (len - 150, &m, &s, &f); @@ -1069,14 +1100,28 @@ int read_toc_entrys (int len) { + int ret; struct ioc_read_toc_entry t; + struct ioc_read_last_session_addr lsa; t.address_format = msf ? CD_MSF_FORMAT : CD_LBA_FORMAT; t.starting_track = 0; t.data_len = len; t.data = toc_buffer; - return (ioctl (fd, CDIOREADTOCENTRYS, (char *) &t)); + ret = ioctl (fd, CDIOREADTOCENTRYS, (char *) &t); + if (ret != 0) + return (ret); + + lsa.address_format = msf ? CD_MSF_FORMAT : CD_LBA_FORMAT; + + ret = ioctl (fd, CDIOREADLASTSESSIONADDR, (char *) &lsa); + if (ret == 0) { + memcpy(&last_session_addr, &lsa.addr, + sizeof(last_session_addr)); + } + + return (0); } int play_msf (int start_m, int start_s, int start_f, Index: sys/cam/scsi/scsi_cd.c =================================================================== --- sys/cam/scsi/scsi_cd.c (revision 190463) +++ sys/cam/scsi/scsi_cd.c (working copy) @@ -253,7 +253,8 @@ u_int32_t sense_flags); static int cdreadtoc(struct cam_periph *periph, u_int32_t mode, u_int32_t start, u_int8_t *data, - u_int32_t len, u_int32_t sense_flags); + u_int32_t len, u_int8_t control, + u_int32_t sense_flags); static int cdgetmode(struct cam_periph *periph, struct cd_mode_params *data, u_int32_t page); static int cdsetmode(struct cam_periph *periph, @@ -2122,7 +2123,8 @@ ("trying to do CDIOREADTOCHEADER\n")); error = cdreadtoc(periph, 0, 0, (u_int8_t *)th, - sizeof (*th), /*sense_flags*/0); + sizeof (*th), /*control*/0, + /*sense_flags*/0); if (error) { free(th, M_SCSICD); cam_periph_unlock(periph); @@ -2174,7 +2176,8 @@ th = &data->header; error = cdreadtoc(periph, 0, 0, (u_int8_t *)th, - sizeof (*th), /*sense_flags*/0); + sizeof (*th), /*control*/0, + /*sense_flags*/0); if (error) { free(data, M_SCSICD); free(lead, M_SCSICD); @@ -2233,6 +2236,7 @@ starting_track, (u_int8_t *)data, readlen + sizeof (*th), + /*control*/0, /*sense_flags*/0); if (error) { free(data, M_SCSICD); @@ -2250,6 +2254,7 @@ error = cdreadtoc(periph, te->address_format, LEADOUT, (u_int8_t *)lead, sizeof(*lead), + /*control*/0, /*sense_flags*/0); if (error) { free(data, M_SCSICD); @@ -2299,7 +2304,8 @@ th = &data->header; error = cdreadtoc(periph, 0, 0, (u_int8_t *)th, - sizeof (*th), /*sense_flags*/0); + sizeof (*th), /*control*/0, + /*sense_flags*/0); if (error) { free(data, M_SCSICD); cam_periph_unlock(periph); @@ -2331,6 +2337,7 @@ error = cdreadtoc(periph, te->address_format, track, (u_int8_t *)data, sizeof(*data), + /*control*/0, /*sense_flags*/0); if (error) { free(data, M_SCSICD); @@ -2346,6 +2353,96 @@ cam_periph_unlock(periph); } break; + case CDIOREADLASTSESSIONADDR: + /* + * An "Enhanced CD" (or "Extra CD") is a CD with audio + * tracks, then data tracks. Audio tracks are in the + * first session, while data tracks are in the second + * session. Because of the space taken by the first + * session's lead-out and the second session's lead-in, + * the duration of the last audio track can't be determined + * with the address of the data track. Therefore, we need + * to get the address of the second (and last) session for + * this purpose. + */ + { + struct cd_toc_single *data; + struct ioc_read_last_session_addr *lsa = + (struct ioc_read_last_session_addr *) addr; + struct ioc_toc_header *th; + + data = malloc(sizeof(*data), M_SCSICD, M_WAITOK); + + cam_periph_lock(periph); + CAM_DEBUG(periph->path, CAM_DEBUG_SUBTRACE, + ("trying to do CDIOREADLASTSESSIONADDR\n")); + + if (lsa->address_format != CD_MSF_FORMAT + && lsa->address_format != CD_LBA_FORMAT) { + printf("error in readlastsessionaddr, " + " returning EINVAL\n"); + free(data, M_SCSICD); + error = EINVAL; + cam_periph_unlock(periph); + break; + } + + th = &data->header; + error = cdreadtoc(periph, 0, 0, (u_int8_t *)th, + sizeof (*th), /*control*/0, + /*sense_flags*/0); + if (error) { + free(data, M_SCSICD); + cam_periph_unlock(periph); + break; + } + + if (softc->quirks & CD_Q_BCD_TRACKS) { + /* we are going to have to convert the BCD + * encoding on the cd to what is expected + */ + th->starting_track = + bcd2bin(th->starting_track); + th->ending_track = bcd2bin(th->ending_track); + } + + if (th->starting_track == LEADOUT) { + /* Linux set an LBA to 0'2" when this is not + * a multisession CD. */ + if (lsa->address_format == CD_MSF_FORMAT) { + lsa->addr.msf.minute = 0; + lsa->addr.msf.second = 2; + lsa->addr.msf.frame = 0; + } else { + lsa->addr.lba = 2 * 75 - 150; + } + + free(data, M_SCSICD); + cam_periph_unlock(periph); + break; + } + + error = cdreadtoc(periph, lsa->address_format, 0, + (u_int8_t *)data, sizeof(*data), + /*control*/1 << 6, + /*sense_flags*/0); + if (error) { + free(data, M_SCSICD); + cam_periph_unlock(periph); + break; + } + + if (lsa->address_format == CD_MSF_FORMAT) { + bcopy(&data->entry.addr, &lsa->addr, + sizeof(lsa->addr)); + } else { + lsa->addr.lba = ntohl(data->entry.addr.lba); + } + + free(data, M_SCSICD); + cam_periph_unlock(periph); + } + break; case CDIOCSETPATCH: { struct ioc_patch *arg = (struct ioc_patch *)addr; @@ -2803,7 +2900,7 @@ * we don't print anything here if we get an error back. */ error = cdreadtoc(periph, 0, 0, (u_int8_t *)toch, sizeof(*toch), - SF_NO_PRINT); + /*control*/0, SF_NO_PRINT); /* * Errors in reading the table of contents aren't fatal, we just * won't have a valid table of contents cached. @@ -2829,7 +2926,7 @@ error = cdreadtoc(periph, CD_MSF_FORMAT, toch->starting_track, (u_int8_t *)&softc->toc, toclen + sizeof(*toch), - SF_NO_PRINT); + /*control*/0, SF_NO_PRINT); if (error != 0) { error = 0; bzero(&softc->toc, sizeof(softc->toc)); @@ -2849,7 +2946,7 @@ error = cdreadtoc(periph, CD_MSF_FORMAT, LEADOUT, (u_int8_t *)&leadout, sizeof(leadout), - SF_NO_PRINT); + /*control*/0, SF_NO_PRINT); if (error != 0) { error = 0; goto bailout; @@ -3139,7 +3236,8 @@ */ static int cdreadtoc(struct cam_periph *periph, u_int32_t mode, u_int32_t start, - u_int8_t *data, u_int32_t len, u_int32_t sense_flags) + u_int8_t *data, u_int32_t len, u_int8_t control, + u_int32_t sense_flags) { struct scsi_read_toc *scsi_cmd; u_int32_t ntoc; @@ -3176,6 +3274,7 @@ scsi_cmd->data_len[1] = (ntoc) & 0xff; scsi_cmd->op_code = READ_TOC; + scsi_cmd->control = control; error = cdrunccb(ccb, cderror, /*cam_flags*/CAM_RETRY_SELTO, /*sense_flags*/SF_RETRY_UA | sense_flags); Index: sys/dev/ata/atapi-cd.c =================================================================== --- sys/dev/ata/atapi-cd.c (revision 190463) +++ sys/dev/ata/atapi-cd.c (working copy) @@ -400,6 +400,25 @@ } break; + case CDIOREADLASTSESSIONADDR: + { + struct ioc_read_last_session_addr *lsa = + (struct ioc_read_last_session_addr *)addr; + + if (!cdp->toc.hdr.ending_track) { + error = EIO; + break; + } + + if (lsa->address_format == CD_MSF_FORMAT) { + lba2msf(cdp->last_session_lba, &lsa->addr.msf.minute, + &lsa->addr.msf.second, &lsa->addr.msf.frame); + } else { + lsa->addr.lba = cdp->last_session_lba; + } + } + break; + #if __FreeBSD_version > 600008 case CDIOCREADSUBCHANNEL_SYSSPACE: nocopyout = 1; @@ -1006,6 +1025,39 @@ cdp->pp[track] = NULL; } + /* + * An "Enhanced CD" (or "Extra CD") is a CD with audio tracks, then + * data tracks. Audio tracks are in the first session, while data + * tracks are in the second session. Because of the space taken by + * the first session's lead-out and the second session's lead-in, + * the duration of the last audio track can't be determined with the + * address of the data track. Therefore, we need to get the address + * of the second (and last) session for this purpose. + */ + if (cdp->toc.hdr.starting_track != 170) { + struct toc last_toc; + + len = sizeof(struct ioc_toc_header) + sizeof(struct cd_toc_entry); + bzero(ccb, sizeof(ccb)); + ccb[0] = ATAPI_READ_TOC; + ccb[7] = len >> 8; + ccb[8] = len; + /* Set this flag to ask for sessions informations instead of tracks + * informations. */ + ccb[9] = 1 << 6; + + if (ata_atapicmd(dev, ccb, (caddr_t)&last_toc, len, + ATA_R_READ | ATA_R_QUIET, 30)) { + bzero(&cdp->toc, sizeof(cdp->toc)); + return; + } + + cdp->last_session_lba = ntohl(last_toc.tab[0].addr.lba); + } else { + /* Linux set an LBA to 0'2" when this is not a multisession CD. */ + cdp->last_session_lba = msf2lba(0, 2, 0); + } + #ifdef ACD_DEBUG if (cdp->disk_size && cdp->toc.hdr.ending_track) { device_printf(dev, "(%d sectors (%d bytes)), %d tracks ", Index: sys/dev/ata/atapi-cd.h =================================================================== --- sys/dev/ata/atapi-cd.h (revision 190463) +++ sys/dev/ata/atapi-cd.h (working copy) @@ -312,4 +312,7 @@ u_int32_t iomax; /* Max I/O request (bytes) */ struct g_geom *gp; /* geom instance */ struct g_provider *pp[MAXTRK+1]; /* providers */ + int last_session_lba; /* last session address (see + CDIOREADLASTSESSIONADDR + ioctl) */ }; Index: sys/sys/cdio.h =================================================================== --- sys/sys/cdio.h (revision 190463) +++ sys/sys/cdio.h (working copy) @@ -281,4 +281,12 @@ */ #define CDIOCREADSUBCHANNEL_SYSSPACE _IOWR('c', 31, struct ioc_read_subchannel) + +struct ioc_read_last_session_addr { + u_char address_format; + union msf_lba addr; +}; +#define CDIOREADLASTSESSIONADDR \ + _IOWR('c', 32, struct ioc_read_last_session_addr) + #endif /* !_SYS_CDIO_H_ */ From jkim at FreeBSD.org Thu Apr 9 08:36:05 2009 From: jkim at FreeBSD.org (Jung-uk Kim) Date: Thu Apr 9 08:36:12 2009 Subject: AMD 780G chipset major issues 1/3 (ata, ataati) In-Reply-To: <49DC6129.4070107@FreeBSD.org> References: <1239063789.00097213.1239052203@10.7.7.3> <83e5fb980904071402k600cbc09hcde8994cb5465f52@mail.gmail.com> <49DC6129.4070107@FreeBSD.org> Message-ID: <200904091135.56144.jkim@FreeBSD.org> On Wednesday 08 April 2009 04:32 am, Alexander Motin wrote: > Diego Depaoli wrote: > > On Tue, Apr 7, 2009 at 10:12 PM, Alexander Motin wrote: > >> Kurt Jaeger wrote: > >>>>> 2 -> with ataati loaded as module > >>> > >>> [...] > >>> > >>>>> ad4: 305245MB at ata2-master > >>>>> SATA300 ad6: 305245MB at > >>>>> ata3-master SATA300 > >>>>> > >>>>> my sata disks are right, but ata1 and acd0 vanished > >>>> > >>>> Is your DVD drive SATA or PATA? > > > > It's PATA > > According to what I have found on the net, this chipset has 6 SATA > and one PATA ports. When you are disabling ataati driver ATA > controllers work in legacy ATA emulation mode, which emulates 8 > possible devices access via 4 legacy PATA channels. > > ataati driver loading switches first controller into native AHCI > mode, which for some reason gives you only four ports, not six, may > be last two are still under the legacy emulation. And disables > second port on PATA controller, which actually should not be there, > but looks like present, according to common driver operation. > > I would say that there is some misconfiguration between BIOS ATA > emulation settings and ataati driver expectations. Is there any > switches like Native/AHCI/RAID/Legacy in your BIOS settings? Have > you tried to play with them? We have to fix many things but you can take a look at the following Linux patches: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/195354 Jung-uk Kim From ohartman at mail.zedat.fu-berlin.de Thu Apr 9 09:56:45 2009 From: ohartman at mail.zedat.fu-berlin.de (O. Hartmann) Date: Thu Apr 9 12:23:39 2009 Subject: firefox3 with high latencies when acting with mouse or keyboard and graphics refresh In-Reply-To: <49DD0A57.7020701@freebsd.org> References: <49DCA9E0.6000109@zedat.fu-berlin.de> <49DD0A57.7020701@freebsd.org> Message-ID: <49DE28D8.1020508@mail.zedat.fu-berlin.de> Tim Kientzle wrote: > I saw something similar recently due to a mismatch > between hald and the xorg server. In my case, it > affected all applications, not just firefox. > * Are you running hald? hald is not running by default. > * Do you have "AllowEmptyInput" set in /etc/X11/xorg.conf? It is explicitely set OFF/NO. > * Are you starting xdm, kdm, or gdm from /etc/ttys? Yes, xdm is started via /etc/ttys. > > Tim > > O. Hartmann wrote: >> Hello, >> got a problem since yesterday after having done a lot of updates >> (ports): on all of my FreeBSD 8.0-CURRENT/amd64 boxes firefox does >> have enormous high latencies when typing in or moving the mouse or >> popping up the window icon or down. Since this happens on all of >> 8.0-CUR/amd boxes, I guess it has something to do with an upgrade of >> the ports. >> >> I reinstalled firefox twice, but without success, so I want to ask >> for some hints.. >> >> Regards, >> Oliver >> _______________________________________________ >> freebsd-current@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-current >> To unsubscribe, send any mail to >> "freebsd-current-unsubscribe@freebsd.org" >> >> From Ggatten at waddell.com Thu Apr 9 11:33:42 2009 From: Ggatten at waddell.com (Gary Gatten) Date: Thu Apr 9 12:24:00 2009 Subject: make install krb5 conflict with heimdal In-Reply-To: <49DE28D8.1020508@mail.zedat.fu-berlin.de> References: <49DCA9E0.6000109@zedat.fu-berlin.de><49DD0A57.7020701@freebsd.org> <49DE28D8.1020508@mail.zedat.fu-berlin.de> Message-ID: <70C0964126D66F458E688618E1CD008A0793E957@WADPEXV0.waddell.com> On FreeBSD 6.0. I have FreeRADIUS installed and functional. Trying to integrate with AD so trying to install SAMBA for the NTLM Auth functions. SAMBA installs failed with a problem with krb5. Finally got the make of krb5 to succeed, but the make install fails with error below. Tried removing heimdal but FreeRADIUS depends on it! Any help getting past this paradox would be GREATLY appreciated! I'm stuck right now and really don't want to uninstall FreeRADIUS. ===> Installing for krb5-1.6.3_5 ===> krb5-1.6.3_5 conflicts with installed package(s): heimdal-1.0.1 They install files into the same place. Please remove them first with pkg_delete(1). *** Error code 1 Stop in /usr/ports/security/krb5. *** Error code 1 Stop in /usr/ports/security/krb5. -----Original Message----- From: owner-freebsd-questions@freebsd.org [mailto:owner-freebsd-questions@freebsd.org] On Behalf Of O. Hartmann Sent: Thursday, April 09, 2009 11:57 AM To: Tim Kientzle Cc: freebsd-current@freebsd.org; O. Hartmann; freebsd-questions@freebsd.org Subject: Re: firefox3 with high latencies when acting with mouse or keyboard and graphics refresh Tim Kientzle wrote: > I saw something similar recently due to a mismatch > between hald and the xorg server. In my case, it > affected all applications, not just firefox. > * Are you running hald? hald is not running by default. > * Do you have "AllowEmptyInput" set in /etc/X11/xorg.conf? It is explicitely set OFF/NO. > * Are you starting xdm, kdm, or gdm from /etc/ttys? Yes, xdm is started via /etc/ttys. > > Tim > > O. Hartmann wrote: >> Hello, >> got a problem since yesterday after having done a lot of updates >> (ports): on all of my FreeBSD 8.0-CURRENT/amd64 boxes firefox does >> have enormous high latencies when typing in or moving the mouse or >> popping up the window icon or down. Since this happens on all of >> 8.0-CUR/amd boxes, I guess it has something to do with an upgrade of >> the ports. >> >> I reinstalled firefox twice, but without success, so I want to ask >> for some hints.. >> >> Regards, >> Oliver >> _______________________________________________ >> freebsd-current@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-current >> To unsubscribe, send any mail to >> "freebsd-current-unsubscribe@freebsd.org" >> >> _______________________________________________ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscribe@freebsd.org"
"This email is intended to be reviewed by only the intended recipient and may contain information that is privileged and/or confidential. If you are not the intended recipient, you are hereby notified that any review, use, dissemination, disclosure or copying of this email and its attachments, if any, is strictly prohibited. If you have received this email in error, please immediately notify the sender by return email and delete this email from your system." From rea-fbsd at codelabs.ru Thu Apr 9 13:02:09 2009 From: rea-fbsd at codelabs.ru (Eygene Ryabinkin) Date: Thu Apr 9 13:02:19 2009 Subject: New rc.d/named features for testing: auto-forwarding and wait on boot In-Reply-To: <49D1B261.6010406@FreeBSD.org> References: <49D1B261.6010406@FreeBSD.org> Message-ID: Doug, everyone, good day. Mon, Mar 30, 2009 at 11:04:17PM -0700, Doug Barton wrote: > For a long time now there has also been discussion about configuring > the local resolver to automatically forward to those name servers in > /etc/resolv.conf. This bit is a lot trickier, primarily because it > involves writing to /etc/namedb/ at boot time. However, the default is > to chroot the named process to /var/named/ so this should be > relatively safe. > > The patch has an implementation of the feature that works for the few > networks I've tested it on. I feel that it is still a bit rough, but > it's ready for wider review. The basic idea is that we parse > /etc/resolv.conf for lines that begin with "nameserver" and try to > make use of the information. It writes a temp file to > /var/run/auto_forward.conf, then when it's done it compares the result > to what's in [/var/named]/etc/namedb/auto_forward.conf. If it's > different, the new one replaces the old. While it's being parsed, if > the local named is not the first nameserver line in /etc/resolv.conf > that is added, and if the new file differs from the existing one it > will be replaced too. This uses roughly the same logic as is used in > /sbin/dhclient-script. Just for the record: once upon a time, http://lists.freebsd.org/pipermail/freebsd-current/2008-April/084847.html I had posted patches that were doing the similar job, but they were mainly focused on the dhclient part. Though, I had implemented creation of /etc/resolv.conf inside /etc/rc.d/resolv in a number of ways: - by using DHCP kenv variables; - by using /etc/rc.conf variables; - by using command-line options to /etc/rc.d/resolv. And that was complemented with the automated creation of the forwarders file for named that is very similar to what you did. There is a hanging PR about this: http://www.freebsd.org/cgi/query-pr.cgi?pr=bin/123015 May be my old patches (that are working on my laptop and some workstations almost for a year) will worth review/integration. Archive with patches could be downloaded from http://codelabs.ru/fbsd/patches/resolv/resolv.named.forwarders.tar.bz2 Comments are reviews are welcome. Thanks! -- Eygene _ ___ _.--. # \`.|\..----...-'` `-._.-'_.-'` # Remember that it is hard / ' ` , __.--' # to read the on-line manual )/' _/ \ `-_, / # while single-stepping the kernel. `-'" `"\_ ,_.-;_.-\_ ', fsc/as # _.-'_./ {_.' ; / # -- FreeBSD Developers handbook {_.-``-' {_/ # From baptiste.daroussin at gmail.com Thu Apr 9 14:02:13 2009 From: baptiste.daroussin at gmail.com (Baptiste Daroussin) Date: Thu Apr 9 14:02:19 2009 Subject: Any clue on ralink rt2860 support? Message-ID: <20090409210208.GB79989@wicklow.lan> Hi all, Is there any progress on the ralink rt2860 wifi chipset support? This is the chipset of the eeepc 1000H. If needed I can do testing. regards, Bapt From admin at lissyara.su Thu Apr 9 15:02:33 2009 From: admin at lissyara.su (Alex Keda) Date: Thu Apr 9 15:02:49 2009 Subject: Any clue on ralink rt2860 support? In-Reply-To: <20090409210208.GB79989@wicklow.lan> References: <20090409210208.GB79989@wicklow.lan> Message-ID: <49DE7086.1040200@lissyara.su> Baptiste Daroussin ?????: > Hi all, > > Is there any progress on the ralink rt2860 wifi chipset support? > This is the chipset of the eeepc 1000H. > If needed I can do testing. http://forums.freebsd.org/showthread.php?t=2475 http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/132672 http://forum.lissyara.su/viewtopic.php?f=8&t=14937 [russian] From matheus at eternamente.info Thu Apr 9 15:03:22 2009 From: matheus at eternamente.info (Nenhum_de_Nos) Date: Thu Apr 9 15:03:28 2009 Subject: ata and seagate microdrive problems Message-ID: <00652174bdc7334a1a2d3d8db7c667a7.squirrel@10.1.1.10> hail, I'm trying to install current on via itx using ide 44pin to cf adapter and a seagate 8GB microdrive. I thought it was to be ok, but just today when I received the adapter I got nowhere in this. I tried 7.1-STABLE and 8.0-CURRENT from 200902, and both fail to find it. the same thing in 7.1R. I found this http://forums.freebsd.org/archive/index.php/t-2733.html, but hw.ata.ata_dma_check_80pin=0 is no good :( and found this pr http://lists.freebsd.org/pipermail/freebsd-bugs/2007-March/022884.html as the only pr that mentions microdrive (I may be wrong). is there anything I can do ? is there a plan to change this ? If I buy an alix 2d3 and try to use this MD will it have the same problem ? I tried the same adapter and sandisk 128MB cf card, no problem. thanks, matheus -- We will call you cygnus, The God of balance you shall be From baptiste.daroussin at gmail.com Thu Apr 9 15:22:52 2009 From: baptiste.daroussin at gmail.com (Baptiste Daroussin) Date: Thu Apr 9 15:22:59 2009 Subject: Any clue on ralink rt2860 support? In-Reply-To: <49DE7086.1040200@lissyara.su> References: <20090409210208.GB79989@wicklow.lan> <49DE7086.1040200@lissyara.su> Message-ID: <20090409222247.GC79989@wicklow.lan> On Fri, Apr 10, 2009 at 02:02:46AM +0400, Alex Keda wrote: > http://forums.freebsd.org/showthread.php?t=2475 > http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/132672 > http://forum.lissyara.su/viewtopic.php?f=8&t=14937 [russian] Thanks i'll keep an eye on this From matheus at eternamente.info Thu Apr 9 15:48:41 2009 From: matheus at eternamente.info (Nenhum_de_Nos) Date: Thu Apr 9 15:49:04 2009 Subject: ata and seagate microdrive problems In-Reply-To: <00652174bdc7334a1a2d3d8db7c667a7.squirrel@10.1.1.10> References: <00652174bdc7334a1a2d3d8db7c667a7.squirrel@10.1.1.10> Message-ID: <4d74dc11b924c49f90f3a4f705d9624b.squirrel@10.1.1.10> On Thu, April 9, 2009 19:03, Nenhum_de_Nos wrote: > hail, > > I'm trying to install current on via itx using ide 44pin to cf adapter and > a seagate 8GB microdrive. > > I thought it was to be ok, but just today when I received the adapter I > got nowhere in this. I tried 7.1-STABLE and 8.0-CURRENT from 200902, and > both fail to find it. the same thing in 7.1R. > > I found this http://forums.freebsd.org/archive/index.php/t-2733.html, but > hw.ata.ata_dma_check_80pin=0 is no good :( > > and found this pr > http://lists.freebsd.org/pipermail/freebsd-bugs/2007-March/022884.html as > the only pr that mentions microdrive (I may be wrong). > > is there anything I can do ? is there a plan to change this ? > > If I buy an alix 2d3 and try to use this MD will it have the same problem > ? > > I tried the same adapter and sandisk 128MB cf card, no problem. just adding information, I have the same problem as http://www.mail-archive.com/support@pfsense.com/msg14933.html thanks, matheus -- We will call you cygnus, The God of balance you shall be From dougb at FreeBSD.org Thu Apr 9 16:10:15 2009 From: dougb at FreeBSD.org (Doug Barton) Date: Thu Apr 9 16:10:27 2009 Subject: New rc.d/named features for testing: auto-forwarding and wait on boot In-Reply-To: References: <49D1B261.6010406@FreeBSD.org> Message-ID: <49DE8048.6050809@FreeBSD.org> Eygene Ryabinkin wrote: > Just for the record: once upon a time, > http://lists.freebsd.org/pipermail/freebsd-current/2008-April/084847.html > I had posted patches that were doing the similar job, but they were > mainly focused on the dhclient part. I have reviewed that stuff, but it does way more than I wanted, and (for obvious reasons) I am more comfortable frobbing just named than I am introducing a lot of other changes at the same time. Doug -- This .signature sanitized for your protection From kwhite at site.uottawa.ca Thu Apr 9 16:30:34 2009 From: kwhite at site.uottawa.ca (kwhite@site.uottawa.ca) Date: Thu Apr 9 16:36:23 2009 Subject: Unable to associate using NDIS driver to WPA/WPA2 APs post 2009/03/26 In-Reply-To: <49DA3BD4.4040900@freebsd.org> References: <20090406092653.W48458@admin16.site.uottawa.ca> <49DA3BD4.4040900@freebsd.org> Message-ID: <51729.137.122.93.93.1239319832.squirrel@courriel.site.uottawa.ca> > Keith White wrote: >> The platform is an msi wind U100 using an NDIS driver for the onboard >> rt2860. >> >> This has worked well, both at home with WPA2-PSK and at work with >> WPA2-EAP, until recently [post 2009/03/26?]. It stopped working >> with the recent changes to if_ndis and net80211. >> >> My current workaround is to use older versions of wlan.ko and >> if_ndis.ko, but that's not going to continue forever... >> > r190579 broke ndis. It appears that r190850 fixed it. Thanks! ...keith From dougb at FreeBSD.org Thu Apr 9 16:38:40 2009 From: dougb at FreeBSD.org (Doug Barton) Date: Thu Apr 9 16:38:47 2009 Subject: Hal and KDM breakage (was Re: KDE4 and input events stalled) In-Reply-To: <49DC405B.7090208@freebsd.org> References: <934e1d760904061455o4736d643o1d07e3292192d94c@mail.gmail.com> <1239078081.1908.41.camel@balrog.2hip.net> <49DAE987.7090802@freebsd.org> <1239086408.35025.59.camel@shumai.marcuscom.com> <20090407185915.GY31409@albert.catwhisker.org> <49DBA371.3080804@freebsd.org> <92cd2ff70904071637h362da63ua13c1f8eca6fc616@mail.gmail.com> <1239147806.98664.12.camel@shumai.marcuscom.com> <92cd2ff70904071653r4bf3b381lf5de220b2e280c0c@mail.gmail.com> <1239150469.98664.18.camel@shumai.marcuscom.com> <49DC405B.7090208@freebsd.org> Message-ID: <49DE86EF.3030409@FreeBSD.org> Not sure if this is even possible, but I thought I'd throw it out there. Would starting hald before ttys are loaded, then restarting it again at the end of the boot process work to solve this issue? It seems that you have 2 distinct 'flavors' of hald here (with vty support, and without), so if it's smart enough to do the right thing for its consumers when it is restarted I think this approach might work. Just a thought, Doug -- This .signature sanitized for your protection From Shelby.Noonan at sandisk.com Thu Apr 9 16:41:36 2009 From: Shelby.Noonan at sandisk.com (Shelby Noonan) Date: Thu Apr 9 17:42:27 2009 Subject: Anyone have an eee 901/1000h kernel I can grab? Message-ID: I am having trouble getting a kernel for my EEE 1000h. The wiki (http://wiki.freebsd.org/AsusEee) says that head should have all the needed bits in it, yet when I compile a head as of friday (3/31/09) I still get no ath_hal lines in dmesg, and the wired ale gets no carrier. I took the EEE_HEAD config from said wiki, but no change. Is something else needed? or even can someone just tar up there working kernel and point me at a place to download it. I just want a working machine, but am running out of things I know how to do to get it there. Thanks for any help Shelby Noonan From tinderbox at freebsd.org Thu Apr 9 19:36:32 2009 From: tinderbox at freebsd.org (FreeBSD Tinderbox) Date: Thu Apr 9 19:36:45 2009 Subject: [head tinderbox] failure on sparc64/sun4v Message-ID: <20090410023628.EA8C27302F@freebsd-current.sentex.ca> TB --- 2009-04-10 01:20:40 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2009-04-10 01:20:40 - starting HEAD tinderbox run for sparc64/sun4v TB --- 2009-04-10 01:20:40 - cleaning the object tree TB --- 2009-04-10 01:21:13 - cvsupping the source tree TB --- 2009-04-10 01:21:13 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/sparc64/sun4v/supfile TB --- 2009-04-10 01:21:21 - building world TB --- 2009-04-10 01:21:21 - MAKEOBJDIRPREFIX=/obj TB --- 2009-04-10 01:21:21 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-04-10 01:21:21 - TARGET=sun4v TB --- 2009-04-10 01:21:21 - TARGET_ARCH=sparc64 TB --- 2009-04-10 01:21:21 - TZ=UTC TB --- 2009-04-10 01:21:21 - __MAKE_CONF=/dev/null TB --- 2009-04-10 01:21:21 - cd /src TB --- 2009-04-10 01:21:21 - /usr/bin/make -B buildworld >>> World build started on Fri Apr 10 01:21:22 UTC 2009 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Fri Apr 10 02:34:58 UTC 2009 TB --- 2009-04-10 02:34:58 - generating LINT kernel config TB --- 2009-04-10 02:34:58 - cd /src/sys/sun4v/conf TB --- 2009-04-10 02:34:58 - /usr/bin/make -B LINT TB --- 2009-04-10 02:34:58 - building LINT kernel TB --- 2009-04-10 02:34:58 - MAKEOBJDIRPREFIX=/obj TB --- 2009-04-10 02:34:58 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-04-10 02:34:58 - TARGET=sun4v TB --- 2009-04-10 02:34:58 - TARGET_ARCH=sparc64 TB --- 2009-04-10 02:34:58 - TZ=UTC TB --- 2009-04-10 02:34:58 - __MAKE_CONF=/dev/null TB --- 2009-04-10 02:34:58 - cd /src TB --- 2009-04-10 02:34:58 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Fri Apr 10 02:34:58 UTC 2009 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies [...] awk -f /src/sys/tools/makeobjops.awk /src/sys/opencrypto/cryptodev_if.m -h awk -f /src/sys/tools/makeobjops.awk /src/sys/dev/ofw/ofw_bus_if.m -h awk -f /src/sys/tools/makeobjops.awk /src/sys/dev/ofw/ofw_if.m -h awk -f /src/sys/tools/makeobjops.awk /src/sys/sun4v/mdesc/mdesc_bus_if.m -h rm -f .newdep /usr/bin/make -V CFILES -V SYSTEM_CFILES -V GEN_CFILES | MKDEP_CPP="cc -E" CC="cc" xargs mkdep -a -f .newdep -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ipfilter -I/src/sys/contrib/pf -I/src/sys/dev/ath -I/src/sys/dev/ath/ath_hal -I/src/sys/contrib/ngatm -I/src/sys/dev/twa -I/src/sys/gnu/fs/xfs/FreeBSD -I/src/sys/gnu/fs/xfs/FreeBSD/support -I/src/sys/gnu/fs/xfs -I/src/sys/contrib/opensolaris/compat -I/src/sys/dev/cxgb -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector cc: /src/sys/dev/ixgbe/ixgbe_82599.c: No such file or directory mkdep: compile failed *** Error code 1 Stop in /obj/sun4v/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-04-10 02:36:28 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-04-10 02:36:28 - ERROR: failed to build lint kernel TB --- 2009-04-10 02:36:28 - 3878.44 user 381.02 system 4547.94 real http://tinderbox.des.no/tinderbox-head-HEAD-sparc64-sun4v.full From tinderbox at freebsd.org Thu Apr 9 21:44:47 2009 From: tinderbox at freebsd.org (FreeBSD Tinderbox) Date: Thu Apr 9 21:45:00 2009 Subject: [head tinderbox] failure on amd64/amd64 Message-ID: <20090410044444.3BB177302F@freebsd-current.sentex.ca> TB --- 2009-04-10 02:40:00 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2009-04-10 02:40:00 - starting HEAD tinderbox run for amd64/amd64 TB --- 2009-04-10 02:40:00 - cleaning the object tree TB --- 2009-04-10 02:41:26 - cvsupping the source tree TB --- 2009-04-10 02:41:26 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/amd64/amd64/supfile TB --- 2009-04-10 02:41:37 - building world TB --- 2009-04-10 02:41:37 - MAKEOBJDIRPREFIX=/obj TB --- 2009-04-10 02:41:37 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-04-10 02:41:37 - TARGET=amd64 TB --- 2009-04-10 02:41:37 - TARGET_ARCH=amd64 TB --- 2009-04-10 02:41:37 - TZ=UTC TB --- 2009-04-10 02:41:37 - __MAKE_CONF=/dev/null TB --- 2009-04-10 02:41:37 - cd /src TB --- 2009-04-10 02:41:37 - /usr/bin/make -B buildworld >>> World build started on Fri Apr 10 02:41:38 UTC 2009 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> stage 5.1: building 32 bit shim libraries >>> World build completed on Fri Apr 10 04:42:02 UTC 2009 TB --- 2009-04-10 04:42:02 - generating LINT kernel config TB --- 2009-04-10 04:42:02 - cd /src/sys/amd64/conf TB --- 2009-04-10 04:42:02 - /usr/bin/make -B LINT TB --- 2009-04-10 04:42:03 - building LINT kernel TB --- 2009-04-10 04:42:03 - MAKEOBJDIRPREFIX=/obj TB --- 2009-04-10 04:42:03 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-04-10 04:42:03 - TARGET=amd64 TB --- 2009-04-10 04:42:03 - TARGET_ARCH=amd64 TB --- 2009-04-10 04:42:03 - TZ=UTC TB --- 2009-04-10 04:42:03 - __MAKE_CONF=/dev/null TB --- 2009-04-10 04:42:03 - cd /src TB --- 2009-04-10 04:42:03 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Fri Apr 10 04:42:03 UTC 2009 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies [...] awk -f /src/sys/tools/makeobjops.awk /src/sys/kern/serdev_if.m -h awk -f /src/sys/tools/makeobjops.awk /src/sys/libkern/iconv_converter_if.m -h awk -f /src/sys/tools/makeobjops.awk /src/sys/opencrypto/cryptodev_if.m -h awk -f /src/sys/tools/makeobjops.awk /src/sys/dev/acpica/acpi_if.m -h rm -f .newdep /usr/bin/make -V CFILES -V SYSTEM_CFILES -V GEN_CFILES | MKDEP_CPP="cc -E" CC="cc" xargs mkdep -a -f .newdep -O2 -frename-registers -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ipfilter -I/src/sys/contrib/pf -I/src/sys/dev/ath -I/src/sys/dev/ath/ath_hal -I/src/sys/contrib/ngatm -I/src/sys/dev/twa -I/src/sys/gnu/fs/xfs/FreeBSD -I/src/sys/gnu/fs/xfs/FreeBSD/support -I/src/sys/gnu/fs/xfs -I/src/sys/contrib/opensolaris/compat -I/src/sys/dev/cxgb -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-ss e3 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector cc: /src/sys/dev/ixgbe/ixgbe_82599.c: No such file or directory mkdep: compile failed *** Error code 1 Stop in /obj/amd64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-04-10 04:44:43 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-04-10 04:44:43 - ERROR: failed to build lint kernel TB --- 2009-04-10 04:44:43 - 5710.57 user 604.70 system 7483.45 real http://tinderbox.des.no/tinderbox-head-HEAD-amd64-amd64.full From tinderbox at freebsd.org Thu Apr 9 22:21:04 2009 From: tinderbox at freebsd.org (FreeBSD Tinderbox) Date: Thu Apr 9 22:21:16 2009 Subject: [head tinderbox] failure on i386/i386 Message-ID: <20090410052100.D432A7302F@freebsd-current.sentex.ca> TB --- 2009-04-10 03:49:19 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2009-04-10 03:49:19 - starting HEAD tinderbox run for i386/i386 TB --- 2009-04-10 03:49:19 - cleaning the object tree TB --- 2009-04-10 03:50:00 - cvsupping the source tree TB --- 2009-04-10 03:50:00 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/i386/i386/supfile TB --- 2009-04-10 03:50:09 - building world TB --- 2009-04-10 03:50:09 - MAKEOBJDIRPREFIX=/obj TB --- 2009-04-10 03:50:09 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-04-10 03:50:09 - TARGET=i386 TB --- 2009-04-10 03:50:09 - TARGET_ARCH=i386 TB --- 2009-04-10 03:50:09 - TZ=UTC TB --- 2009-04-10 03:50:09 - __MAKE_CONF=/dev/null TB --- 2009-04-10 03:50:09 - cd /src TB --- 2009-04-10 03:50:09 - /usr/bin/make -B buildworld >>> World build started on Fri Apr 10 03:50:13 UTC 2009 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Fri Apr 10 05:12:36 UTC 2009 TB --- 2009-04-10 05:12:36 - generating LINT kernel config TB --- 2009-04-10 05:12:36 - cd /src/sys/i386/conf TB --- 2009-04-10 05:12:36 - /usr/bin/make -B LINT TB --- 2009-04-10 05:12:36 - building LINT kernel TB --- 2009-04-10 05:12:36 - MAKEOBJDIRPREFIX=/obj TB --- 2009-04-10 05:12:36 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-04-10 05:12:36 - TARGET=i386 TB --- 2009-04-10 05:12:36 - TARGET_ARCH=i386 TB --- 2009-04-10 05:12:36 - TZ=UTC TB --- 2009-04-10 05:12:36 - __MAKE_CONF=/dev/null TB --- 2009-04-10 05:12:36 - cd /src TB --- 2009-04-10 05:12:36 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Fri Apr 10 05:12:36 UTC 2009 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/dev/ed/if_ed_pci.c awk -f /src/sys/tools/makeobjops.awk /src/sys/dev/eisa/eisa_if.m -c ; cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue eisa_if.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/dev/eisa/eisaconf.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/dev/e1000/if_em.c -I/src/sys/dev/e1000 cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/dev/e1000/if_igb.c -I/src/sys/dev/e1000 cc1: warnings being treated as errors /src/sys/dev/e1000/if_igb.c: In function 'igb_print_debug_info': /src/sys/dev/e1000/if_igb.c:4609: warning: format '%lu' expects type 'long unsigned int', but argument 3 has type 'u64' *** Error code 1 Stop in /obj/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-04-10 05:21:00 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-04-10 05:21:00 - ERROR: failed to build lint kernel TB --- 2009-04-10 05:21:00 - 4295.70 user 430.24 system 5500.83 real http://tinderbox.des.no/tinderbox-head-HEAD-i386-i386.full From baptiste.daroussin at gmail.com Thu Apr 9 23:06:21 2009 From: baptiste.daroussin at gmail.com (Baptiste Daroussin) Date: Thu Apr 9 23:06:27 2009 Subject: Anyone have an eee 901/1000h kernel I can grab? In-Reply-To: References: Message-ID: <20090410060616.GD79989@wicklow.lan> On Thu, Apr 09, 2009 at 04:31:22PM -0700, Shelby Noonan wrote: > I am having trouble getting a kernel for my EEE 1000h. The wiki > (http://wiki.freebsd.org/AsusEee) says that head should have all the > needed bits in it, yet when I compile a head as of friday (3/31/09) I > still get no ath_hal lines in dmesg, and the wired ale gets no carrier. > I took the EEE_HEAD config from said wiki, but no change. Is something > else needed? or even can someone just tar up there working kernel and > point me at a place to download it. I just want a working machine, but > am running out of things I know how to do to get it there. > > Thanks for any help > > Shelby Noonan > 1000H doesn't have an ath wifi chipset, but it has a ral (rt2860) which isn't supported yet, in latest current ndis is broken using the latest windows driver. Currently I use a rum device (usb stick) to connect to wifi. regards, Bapt From tinderbox at freebsd.org Thu Apr 9 23:14:22 2009 From: tinderbox at freebsd.org (FreeBSD Tinderbox) Date: Thu Apr 9 23:14:35 2009 Subject: [head tinderbox] failure on i386/pc98 Message-ID: <20090410061418.EA00C7302F@freebsd-current.sentex.ca> TB --- 2009-04-10 04:44:44 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2009-04-10 04:44:44 - starting HEAD tinderbox run for i386/pc98 TB --- 2009-04-10 04:44:44 - cleaning the object tree TB --- 2009-04-10 04:45:15 - cvsupping the source tree TB --- 2009-04-10 04:45:15 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/i386/pc98/supfile TB --- 2009-04-10 04:45:24 - building world TB --- 2009-04-10 04:45:24 - MAKEOBJDIRPREFIX=/obj TB --- 2009-04-10 04:45:24 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-04-10 04:45:24 - TARGET=pc98 TB --- 2009-04-10 04:45:24 - TARGET_ARCH=i386 TB --- 2009-04-10 04:45:24 - TZ=UTC TB --- 2009-04-10 04:45:24 - __MAKE_CONF=/dev/null TB --- 2009-04-10 04:45:24 - cd /src TB --- 2009-04-10 04:45:24 - /usr/bin/make -B buildworld >>> World build started on Fri Apr 10 04:45:26 UTC 2009 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Fri Apr 10 06:07:33 UTC 2009 TB --- 2009-04-10 06:07:33 - generating LINT kernel config TB --- 2009-04-10 06:07:33 - cd /src/sys/pc98/conf TB --- 2009-04-10 06:07:33 - /usr/bin/make -B LINT TB --- 2009-04-10 06:07:33 - building LINT kernel TB --- 2009-04-10 06:07:33 - MAKEOBJDIRPREFIX=/obj TB --- 2009-04-10 06:07:33 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-04-10 06:07:33 - TARGET=pc98 TB --- 2009-04-10 06:07:33 - TARGET_ARCH=i386 TB --- 2009-04-10 06:07:33 - TZ=UTC TB --- 2009-04-10 06:07:33 - __MAKE_CONF=/dev/null TB --- 2009-04-10 06:07:33 - cd /src TB --- 2009-04-10 06:07:33 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Fri Apr 10 06:07:33 UTC 2009 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/dev/ed/if_ed_pccard.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/dev/ed/if_ed_pci.c awk -f /src/sys/tools/makeobjops.awk /src/sys/dev/eisa/eisa_if.m -c ; cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue eisa_if.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/dev/e1000/if_em.c -I/src/sys/dev/e1000 cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/dev/e1000/if_igb.c -I/src/sys/dev/e1000 cc1: warnings being treated as errors /src/sys/dev/e1000/if_igb.c: In function 'igb_print_debug_info': /src/sys/dev/e1000/if_igb.c:4609: warning: format '%lu' expects type 'long unsigned int', but argument 3 has type 'u64' *** Error code 1 Stop in /obj/pc98/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-04-10 06:14:18 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-04-10 06:14:18 - ERROR: failed to build lint kernel TB --- 2009-04-10 06:14:18 - 4179.80 user 435.16 system 5374.38 real http://tinderbox.des.no/tinderbox-head-HEAD-i386-pc98.full From ale at FreeBSD.org Fri Apr 10 06:29:22 2009 From: ale at FreeBSD.org (Alex Dupre) Date: Fri Apr 10 06:29:30 2009 Subject: xorg loops In-Reply-To: <1239176118.1954.11.camel@balrog.2hip.net> References: <49D8D03B.8090302@arcor.de> <3a142e750904050919l1388b559t9bbd751546e239e7@mail.gmail.com> <1238957462.1829.8.camel@balrog.2hip.net> <49D90363.6010602@arcor.de> <1238959921.1829.10.camel@balrog.2hip.net> <49DB573C.3020703@FreeBSD.org> <1239129677.1947.14.camel@balrog.2hip.net> <49DC5066.1010607@FreeBSD.org> <1239176118.1954.11.camel@balrog.2hip.net> Message-ID: <49DF49AD.30701@FreeBSD.org> Robert Noland ha scritto: > So, I think your issue is probably related to the other thread. "Re: Hal > and KDM breakage". Nope :-( I have the same symptoms without using kdm and without launching it from /etc/ttys. Actually the mouse doesn't work even if I kill moused. The only way to make it working is setting AllowEmptyInput to off, nothing else works. -- Alex Dupre From nakal at web.de Fri Apr 10 07:06:56 2009 From: nakal at web.de (Martin) Date: Fri Apr 10 07:07:03 2009 Subject: Anyone have an eee 901/1000h kernel I can grab? In-Reply-To: References: Message-ID: <20090410154142.499670e5@zelda.local> Am Thu, 9 Apr 2009 16:31:22 -0700 schrieb "Shelby Noonan" : > I am having trouble getting a kernel for my EEE 1000h. The wiki > (http://wiki.freebsd.org/AsusEee) says that head should have all the > needed bits in it, yet when I compile a head as of friday (3/31/09) I > still get no ath_hal lines in dmesg, and the wired ale gets no > carrier. I took the EEE_HEAD config from said wiki, but no change. Is > something else needed? or even can someone just tar up there working > kernel and point me at a place to download it. I just want a working > machine, but am running out of things I know how to do to get it > there. No. The official wiki is wrong. I have already said that before. Apparently, people mix up 901/904, 1000H and 1002HA here. All of them have differences in their hardware configuration. 904 and 1002HA have got an atheros wireless chipset that works with FreeBSD. 901 and 1000H do not work. Their wireless chipsets are ralink based and won't work, even when you install latest -CURRENT. Work on the chipsets shows no progress, as far as I understood it. Everyone who worked on a port from OpenBSD got bored or something like that. -- Martin From amdmi3 at amdmi3.ru Fri Apr 10 07:36:35 2009 From: amdmi3 at amdmi3.ru (Dmitry Marakasov) Date: Fri Apr 10 07:36:42 2009 Subject: cpuset_t vs. cpu_set_t Message-ID: <20090410140908.GA81025@hades.panopticon> I keep running into software that expects cpu_set_t type instead of cpuset_t (namely graphics/osg, devel/ace). Is it us using nonstandart name, or is it them? Also, can it be possible to typedef/define cpu_set_t as cpuset_t? -- Dmitry Marakasov . 55B5 0596 FF1E 8D84 5F56 9510 D35A 80DD F9D2 F77D amdmi3@amdmi3.ru ..: jabber: amdmi3@jabber.ru http://www.amdmi3.ru From kientzle at freebsd.org Fri Apr 10 14:32:32 2009 From: kientzle at freebsd.org (Tim Kientzle) Date: Fri Apr 10 14:32:39 2009 Subject: xorg loops In-Reply-To: <49DF49AD.30701@FreeBSD.org> References: <49D8D03B.8090302@arcor.de> <3a142e750904050919l1388b559t9bbd751546e239e7@mail.gmail.com> <1238957462.1829.8.camel@balrog.2hip.net> <49D90363.6010602@arcor.de> <1238959921.1829.10.camel@balrog.2hip.net> <49DB573C.3020703@FreeBSD.org> <1239129677.1947.14.camel@balrog.2hip.net> <49DC5066.1010607@FreeBSD.org> <1239176118.1954.11.camel@balrog.2hip.net> <49DF49AD.30701@FreeBSD.org> Message-ID: <49DFBAEF.1080904@freebsd.org> Alex Dupre wrote: > Robert Noland ha scritto: >> So, I think your issue is probably related to the other thread. "Re: Hal >> and KDM breakage". > > Nope :-( I have the same symptoms without using kdm and without > launching it from /etc/ttys. Actually the mouse doesn't work even if I > kill moused. The only way to make it working is setting AllowEmptyInput > to off, nothing else works. Are you running hald? On my system: AllowEmptyInput hald Result off enabled Mouse/keyboard delays/jerkiness off disabled Works on (default) enabled Works on (default) disabled No mouse/keyboard Cheers, Tim From yanefbsd at gmail.com Fri Apr 10 17:04:09 2009 From: yanefbsd at gmail.com (Garrett Cooper) Date: Fri Apr 10 17:04:16 2009 Subject: New ioctl to support Enhanced CD (or Extra CD) In-Reply-To: <49DDF942.9040808@FreeBSD.org> References: <49DDF942.9040808@FreeBSD.org> Message-ID: <7d6fde3d0904101704l57e86d69uf7f8297cea14a439@mail.gmail.com> On Thu, Apr 9, 2009 at 6:33 AM, Jean-S?bastien P?dron wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hello, > > Enhanced CD (or Extra CA) is an Audio CD with an additionnal data track > at the end. Audio tracks belong to the first session while the data > track belongs to the second session. Therefore the last audio track ends > way before the data track start. > > The first consequence is that the duration of the last audio track isn't > reported correctly. Here is the output of cdcontrol(1) with such a CD[1]: > ? ?$ cdcontrol info > ? ?... > ? ?12 ?46:03.67 ? 9:54.43 ?207142 ? 44593 ?audio > ? ?13 ?55:58.35 ? 6:38.51 ?251735 ? 29901 ? data > > The expected output is: > ? ?$ cdcontrol info > ? ?... > ? ?12 ?46:03.67 ? 7:22.43 ?207142 ? 33193 ?audio > ? ?13 ?55:58.35 ? 6:38.51 ?251735 ? 29901 ? data > > A more "audible" consequence is that cdparanoia(1) copies 9'54" of data > instead of 7'22". The end of the ripped file is full of garbage. > > I made a patch (attached) that adds a new ioctl to query the start > address of the last session. This new ioctl is named > CDIOREADLASTSESSIONADDR. The patch also includes changes to cdcontrol(1). > > I added a new member at the end of struct acd_softc to store the last > session address. I don't know if this causes ABI breakage. > > Linux' corresponding ioctl is CDROMMULTISESSION. Beside this address, it > returns a flag named "xa_flag". Currently, I don't understand what it is > but it may be useful to add it to our ioctl too if someone knows its > purpose. > > Before I spend some time to teach cdparanoia(1) about this new ioctl, > I'd like some feedback on this patch, especially the name and the struct > ioc_read_last_session_addr. I would appreciate some test reports too! :) > > [1] This was tested with Avishai Cohen's last album, "Aurora". Cool! I'll give this a shot with some CD's I have kicking around my room this weekend -- thanks! -Garrett From trebestie at gmail.com Fri Apr 10 17:26:18 2009 From: trebestie at gmail.com (Diego Depaoli) Date: Fri Apr 10 17:26:24 2009 Subject: AMD 780G chipset major issues 1/3 (ata, ataati) In-Reply-To: <49DC6129.4070107@FreeBSD.org> References: <1239063789.00097213.1239052203@10.7.7.3> <49DBAEB5.7010500@FreeBSD.org> <20090407200257.GB19850@home.opsec.eu> <49DBB3C0.9010800@FreeBSD.org> <83e5fb980904071402k600cbc09hcde8994cb5465f52@mail.gmail.com> <49DC6129.4070107@FreeBSD.org> Message-ID: <83e5fb980904101726m54af3a4boe875854b7e9bd11e@mail.gmail.com> On Wed, Apr 8, 2009 at 10:32 AM, Alexander Motin wrote: > > You can try to comment out 'ctlr->channels = 1;' line in your ata-ati.c > file to allow second channel of the second controller to be attached. I'm sorry, did not help. Regards -- Diego Depaoli From hselasky at c2i.net Sat Apr 11 04:23:54 2009 From: hselasky at c2i.net (Hans Petter Selasky) Date: Sat Apr 11 04:24:01 2009 Subject: axe(4) (Belkin F5D5055) problems In-Reply-To: <2e77fc10904082334v3fc9676cy97ad97f4e7fe6d0a@mail.gmail.com> References: <2e77fc10903280259s5a761cacs398b88649a2367fe@mail.gmail.com> <20090409010953.GE37714@michelle.cdnetworks.co.kr> <2e77fc10904082334v3fc9676cy97ad97f4e7fe6d0a@mail.gmail.com> Message-ID: <200904111326.25342.hselasky@c2i.net> On Thursday 09 April 2009, Niki Denev wrote: > On Thu, Apr 9, 2009 at 4:09 AM, Pyun YongHyeon wrote: > > On Wed, Apr 08, 2009 at 09:45:26AM +0300, Niki Denev wrote: > > >> Also the SiS191 seems to have problems negotiating gigabit link, there > >> are many posts about this > >> when using Linux. > > > > This could be related with PHY handling bug of Linux sis190 driver. > > Because Linux does not have mii(4) it have to poke PHY registers in > > driver layer which ?in turn would make it hard to support various > > PHY hardwares. > > I've noticed this. The linux drives seems to write some magic numbers to > the hardware at several places... very confusing. > Hi, If the device is connected at the end of more than one HUB, then the following patch might solve the problem. Else the following patch will have no effect. http://perforce.freebsd.org/chv.cgi?CH=160485 --HPS From freebsd-listen at fabiankeil.de Sat Apr 11 04:56:43 2009 From: freebsd-listen at fabiankeil.de (Fabian Keil) Date: Sat Apr 11 04:56:52 2009 Subject: New ioctl to support Enhanced CD (or Extra CD) In-Reply-To: <49DDF942.9040808@FreeBSD.org> References: <49DDF942.9040808@FreeBSD.org> Message-ID: <20090411135513.6f34a73b@fabiankeil.de> Jean-S?bastien P?dron wrote: > Enhanced CD (or Extra CA) is an Audio CD with an additionnal data track > at the end. Audio tracks belong to the first session while the data > track belongs to the second session. Therefore the last audio track ends > way before the data track start. > > The first consequence is that the duration of the last audio track isn't > reported correctly. Here is the output of cdcontrol(1) with such a CD[1]: > $ cdcontrol info > ... > 12 46:03.67 9:54.43 207142 44593 audio > 13 55:58.35 6:38.51 251735 29901 data > > The expected output is: > $ cdcontrol info > ... > 12 46:03.67 7:22.43 207142 33193 audio > 13 55:58.35 6:38.51 251735 29901 data > > A more "audible" consequence is that cdparanoia(1) copies 9'54" of data > instead of 7'22". The end of the ripped file is full of garbage. > > I made a patch (attached) that adds a new ioctl to query the start > address of the last session. This new ioctl is named > CDIOREADLASTSESSIONADDR. The patch also includes changes to cdcontrol(1). > > I added a new member at the end of struct acd_softc to store the last > session address. I don't know if this causes ABI breakage. > > Linux' corresponding ioctl is CDROMMULTISESSION. Beside this address, it > returns a flag named "xa_flag". Currently, I don't understand what it is > but it may be useful to add it to our ioctl too if someone knows its > purpose. > > Before I spend some time to teach cdparanoia(1) about this new ioctl, > I'd like some feedback on this patch, especially the name and the struct > ioc_read_last_session_addr. I would appreciate some test reports too! :) Does cdda2wav fail to rip the disc, too? I always rip CDs with cdda2wav and don't remember ever having problems with Audio CDs with additional data tracks on them. Here's an example: fk@TP51 /tank/iriver-spiegel/vorbis $cdrecord dev=1,0,0 -toc Cdrecord-ProDVD-ProBD-Clone 2.01.01a58 (i386-unknown-freebsd8.0) Copyright (C) 1995-2009 J?rg Schilling scsidev: '1,0,0' scsibus: 1 target: 0 lun: 0 Using libscg version 'schily-0.9'. Device type : Removable CD-ROM Version : 0 Response Format: 2 Capabilities : Vendor_info : 'HL-DT-ST' Identifikation : 'RW/DVD GCC-4241N' Revision : '1.04' Device seems to be: Generic mmc2 DVD-ROM. Using generic SCSI-3/mmc CD-R/CD-RW driver (mmc_cdr). Driver flags : MMC-3 SWABAUDIO BURNFREE Supported modes: TAO PACKET SAO SAO/R96P SAO/R96R RAW/R16 RAW/R96P RAW/R96R cdrecord: Warning: The DMA speed test has been skipped. first: 1 last 16 track: 1 lba: 0 ( 0) 00:02:00 adr: 1 control: 0 mode: -1 track: 2 lba: 18082 ( 72328) 04:03:07 adr: 1 control: 0 mode: -1 track: 3 lba: 31630 ( 126520) 07:03:55 adr: 1 control: 0 mode: -1 track: 4 lba: 46795 ( 187180) 10:25:70 adr: 1 control: 0 mode: -1 track: 5 lba: 63665 ( 254660) 14:10:65 adr: 1 control: 0 mode: -1 track: 6 lba: 80502 ( 322008) 17:55:27 adr: 1 control: 0 mode: -1 track: 7 lba: 86587 ( 346348) 19:16:37 adr: 1 control: 0 mode: -1 track: 8 lba: 109885 ( 439540) 24:27:10 adr: 1 control: 0 mode: -1 track: 9 lba: 119572 ( 478288) 26:36:22 adr: 1 control: 0 mode: -1 track: 10 lba: 130400 ( 521600) 29:00:50 adr: 1 control: 0 mode: -1 track: 11 lba: 147227 ( 588908) 32:45:02 adr: 1 control: 0 mode: -1 track: 12 lba: 165110 ( 660440) 36:43:35 adr: 1 control: 0 mode: -1 track: 13 lba: 175982 ( 703928) 39:08:32 adr: 1 control: 0 mode: -1 track: 14 lba: 202420 ( 809680) 45:00:70 adr: 1 control: 0 mode: -1 track: 15 lba: 228530 ( 914120) 50:49:05 adr: 1 control: 4 mode: 2 track: 16 lba: 255626 ( 1022504) 56:50:26 adr: 1 control: 4 mode: 2 track:lout lba: 316474 ( 1265896) 70:21:49 adr: 1 control: 4 mode: -1 cdcontrol reports an incorrect duration for track 14: fk@TP51 /tank/iriver-spiegel/vorbis $cdcontrol info Starting track = 1, ending track = 16, TOC size = 138 bytes track start duration block length type ------------------------------------------------- 1 0:02.00 4:01.07 0 18082 audio 2 4:03.07 3:00.48 18082 13548 audio 3 7:03.55 3:22.15 31630 15165 audio 4 10:25.70 3:44.70 46795 16870 audio 5 14:10.65 3:44.37 63665 16837 audio 6 17:55.27 1:21.10 80502 6085 audio 7 19:16.37 5:10.48 86587 23298 audio 8 24:27.10 2:09.12 109885 9687 audio 9 26:36.22 2:24.28 119572 10828 audio 10 29:00.50 3:44.27 130400 16827 audio 11 32:45.02 3:58.33 147227 17883 audio 12 36:43.35 2:24.72 165110 10872 audio 13 39:08.32 5:52.38 175982 26438 audio 14 45:00.70 5:48.10 202420 26110 audio 15 50:49.05 6:01.21 228530 27096 data 16 56:50.26 13:31.23 255626 60848 data 170 70:21.49 - 316474 - - But cdda2wav gets it right and rips the audio tracks correctly: fk@TP51 /tank/iriver-spiegel/vorbis $cdda2wav -B dev=1,0,0 -paranoia Type: ROM, Vendor 'HL-DT-ST' Model 'RW/DVD GCC-4241N' Revision '1.04' MMC+CDDA 307200 bytes buffer memory requested, transfer size 65536 bytes, 4 buffers, 27 sectors #Cdda2wav version 2.01.01a58_freebsd_8.0_i386_i386, real time sched., soundcard, libparanoia support AUDIOtrack pre-emphasis copy-permitted tracktype channels 1-14 no no audio 2 DATAtrack recorded copy-permitted tracktype 15-16 uninterrupted no data Table of Contents: total tracks:16, (total time 70:19.49) 1.( 4:01.07), 2.( 3:00.48), 3.( 3:22.15), 4.( 3:44.70), 5.( 3:44.37), 6.( 1:21.10), 7.( 5:10.48), 8.( 2:09.12), 9.( 2:24.28), 10.( 3:44.27), 11.( 3:58.33), 12.( 2:24.72), 13.( 5:52.38), 14.| 3:16.10|, 15.[ 6:01.21], 16.[19:32.44] Table of Contents: starting sectors 1.( 0), 2.( 18082), 3.( 31630), 4.( 46795), 5.( 63665), 6.( 80502), 7.( 86587), 8.( 109885), 9.( 119572), 10.( 130400), 11.( 147227), 12.( 165110), 13.( 175982), 14.( 202420), 15.( 228530), 16.( 255626), lead-out( 316474) CDINDEX discid: kbNkxvXP4ppH.K8LpGB5MxaqEp0- CDDB discid: 0xc9107b10 CD-Text: detected CD-Extra: not detected Album title: 'FASHION NUGGET' [from CAKE] Track 1: 'FRANK SINATRA' [...] Track 14: 'SAD SONGS AND WALTZES' samplefile size will be 510689804 bytes. recording 2895.0666 seconds stereo with 16 bits @ 44100.0 Hz ->'audio'... using lib paranoia for reading. cdda2wav: Operation not permitted. cannot set posix realtime scheduling policy percent_done: 100% track 1 'FRANK SINATRA' recorded successfully 100% 0 rderr, 0 skip, 0 atom, 0 edge, 0 drop, 0 dup, 0 drift 100% 241 overlap(0.5 .. 0.5) [...] 100% track 14 'SAD SONGS AND WALTZES' recorded successfully 100% 0 rderr, 0 skip, 0 atom, 0 edge, 0 drop, 0 dup, 0 drift 100% 200 overlap(0.5 .. 0.5) I never understood why people are still using cdparanoia ... Fabian -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 196 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20090411/544685d0/signature.pgp From matheus at eternamente.info Sat Apr 11 05:20:40 2009 From: matheus at eternamente.info (Nenhum_de_Nos) Date: Sat Apr 11 05:20:47 2009 Subject: ata and seagate microdrive problems In-Reply-To: <4d74dc11b924c49f90f3a4f705d9624b.squirrel@10.1.1.10> References: <00652174bdc7334a1a2d3d8db7c667a7.squirrel@10.1.1.10> <4d74dc11b924c49f90f3a4f705d9624b.squirrel@10.1.1.10> Message-ID: <6d9a3f45a9df6707847d5f3aa8c61b1e.squirrel@10.1.1.10> On Thu, April 9, 2009 19:48, Nenhum_de_Nos wrote: > > On Thu, April 9, 2009 19:03, Nenhum_de_Nos wrote: >> hail, >> >> I'm trying to install current on via itx using ide 44pin to cf adapter >> and >> a seagate 8GB microdrive. >> >> I thought it was to be ok, but just today when I received the adapter I >> got nowhere in this. I tried 7.1-STABLE and 8.0-CURRENT from 200902, and >> both fail to find it. the same thing in 7.1R. >> >> I found this http://forums.freebsd.org/archive/index.php/t-2733.html, >> but >> hw.ata.ata_dma_check_80pin=0 is no good :( >> >> and found this pr >> http://lists.freebsd.org/pipermail/freebsd-bugs/2007-March/022884.html >> as >> the only pr that mentions microdrive (I may be wrong). >> >> is there anything I can do ? is there a plan to change this ? >> >> If I buy an alix 2d3 and try to use this MD will it have the same >> problem >> ? >> >> I tried the same adapter and sandisk 128MB cf card, no problem. > > just adding information, I have the same problem as > http://www.mail-archive.com/support@pfsense.com/msg14933.html > > thanks, > > matheus no one ? as for the time being, the pr was filed in 2007 and so far not one message from devs, so I assume is a dead matter, right ? I hope to hear anything, even if its "forget it, won't be worked on". so I know I won't spend time on a dead end. thanks, matheus -- We will call you cygnus, The God of balance you shall be From wblock at wonkity.com Sat Apr 11 11:29:47 2009 From: wblock at wonkity.com (Warren Block) Date: Sat Apr 11 11:29:59 2009 Subject: ata and seagate microdrive problems Message-ID: On Thu, April 9, 2009 19:48, Nenhum_de_Nos wrote: > > I'm trying to install current on via itx using ide 44pin to cf > adapter and a seagate 8GB microdrive. > > I thought it was to be ok, but just today when I received the adapter > I got nowhere in this. I tried 7.1-STABLE and 8.0-CURRENT from > 200902, and both fail to find it. the same thing in 7.1R. "Fail to find it" is a little vague. Is the CF card detected by the BIOS? Many CF-to-IDE adapters don't support DMA: http://lists.freebsd.org/pipermail/freebsd-small/2005-July/000441.html Lack of DMA support in the adapter results in errors, lots of them, after the kernel boots. Disabling DMA as above fixed that on a 2G CF card and CF-to-IDE adapter for me. -Warren Block * Rapid City, South Dakota USA From saifi.khan at twincling.org Sat Apr 11 11:53:04 2009 From: saifi.khan at twincling.org (Saifi Khan) Date: Sat Apr 11 11:53:11 2009 Subject: FreeBSD 8.x, Xen 3.3.x Dom0 support Message-ID: Hi: Does anybody know the extent of Dom0 support for FreeBSD 8.x with Xen 3.3.x ? The discussion threads on -xen and -virtualization are fairly sketchy on this topic. Any pointers or observations ? thanks Saifi. From ndenev at gmail.com Sat Apr 11 13:01:11 2009 From: ndenev at gmail.com (Nikolay Denev) Date: Sat Apr 11 13:01:21 2009 Subject: axe(4) (Belkin F5D5055) problems Message-ID: <75656435-49E2-457A-9CFE-8706CD44916E@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello, I'm running -current from 23.03.09 and I'm experiencing some axe(4) problems. Basically the network connection works but when some more serious traffic hits the interface (i.e. torrent download) it then dies, ifconfig down/up does not help, only replugging of the adapter. I've tried running with hw.usb2.axe.debug=15 and the output was many lines of: axe_bulk_write_callback:853: transfer complete then a pause of several seconds and the kernel begins to print : axe_bulk_write_callback:925: transfer error, USB_ERR_TIMEOUT Another strange thing that I noticed is that, while the interface seems to be connected and working, if I type many times ifconfig ue0 consecutively most of the time it would show different settings for the auto negotiated link. I.e. it would cycle between 100baseTX-FDX, 1000baseT-FDX, no carrier, 100BaseT-FDX hw-loopback and 1000BaseT-FDX hw-loopback. The switch does not seem to register link flaps. The kernel messages for the interface are : ugen2.5: at usbus2 axe0: on usbus2 axe0: PHYADDR 0xe0:0x01 miibus0: on axe0 ukphy0: PHY 1 on miibus0 ukphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto ue0: on axe0 ue0: Ethernet address: 00:11:50:xx:xx:xx devinfo -vr | grep phy ukphy0 pnpinfo oui=0xa0bc model=0x1 rev=0x2 at phyno=1 - -- Regards, Nikolay Denev -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (Darwin) iEYEARECAAYFAknNJX8ACgkQHNAJ/fLbfrmx9QCfYYKrUtXGy5V7k46mwc6Hgy/C m6sAni6ua4JNBBgiKSlS8kHBX4CTmYpQ =7TLQ -----END PGP SIGNATURE----- From alc at cs.rice.edu Sat Apr 11 16:04:03 2009 From: alc at cs.rice.edu (Alan Cox) Date: Sat Apr 11 16:04:10 2009 Subject: [Fwd: svn commit: r190949 - head/sys/vm] Message-ID: <49E11CE7.5050903@cs.rice.edu> It's possible that this could cause problems for "exotic" languages that do their own memory management, i.e., they don't use libc's malloc(). If anyone experiences or hears of such things, please let me know so that we can get the problems sorted out well before the 8.0 release. Alan -------------- next part -------------- An embedded message was scrubbed... From: Alan Cox Subject: svn commit: r190949 - head/sys/vm Date: Sat, 11 Apr 2009 22:34:09 +0000 (UTC) Size: 3588 Url: http://lists.freebsd.org/pipermail/freebsd-current/attachments/20090411/fa971127/vm.eml From kientzle at freebsd.org Sat Apr 11 21:14:02 2009 From: kientzle at freebsd.org (Tim Kientzle) Date: Sat Apr 11 21:14:09 2009 Subject: ZFS/extattr lockup (was Re: bsdtar lockup on Current-03/10/2009) In-Reply-To: <200903112229.41052.lists@jnielsen.net> References: <200903100104.53847.ken__6247.10998167775$1236647281$gmane$org@mthelicon.com> <200903102310.32735.lists@jnielsen.net> <49B73F99.9010200@freebsd.org> <200903112229.41052.lists@jnielsen.net> Message-ID: <49E16A89.3030108@freebsd.org> John Nielsen wrote: > On Wednesday 11 March 2009 12:35:37 am Tim Kientzle wrote: >> John Nielsen wrote: >>> I today noticed the same problem on -CURRENT i386 built March 9. >>> ... using ZFS and initially >>> thought that was the source of the regression but I haven't produced >>> the lockup with anything but tar and the extattr removal hack seems >>> to have fixed it for now ... >> The common element so far seems to be ZFS. Can you verify that >> >> $ lsextattr -h user >> >> hangs on your system as well? That invokes the same >> extattr_list_link system call used by tar to enumerate >> the extended attributes on a file. > > Confirmed. I ran the command on a file in /root (UFS) with no problem. > Running again on a file in /home/john (ZFS) caused the hang. John Baldwin committed a fix for the ZFS problem (r189967, 2009-03-18 16:19:44UTC), so this should be fixed. Could you verify that lsextattr no longer hangs the kernel after this point? Could you verify that re-enabling extended attribute archiving in tar no longer hangs? I'd like to enable the extended attribute support in tar for real if this is really fixed. Thanks, Tim P.S. Here's the patch to enable extended attribute archiving in tar: Index: lib/libarchive/config_freebsd.h =================================================================== --- config_freebsd.h (revision 190954) +++ config_freebsd.h (working copy) @@ -34,12 +34,8 @@ #define HAVE_ACL_SET_FD_NP 1 #define HAVE_ACL_SET_FILE 1 #define HAVE_ACL_USER 1 -#if 0 -/* XXX Temporarily disable support for reading extended attributes from - * disk, as it seems to be badly broken on ZFS. XXX */ #define HAVE_EXTATTR_GET_FILE 1 #define HAVE_EXTATTR_LIST_FILE 1 -#endif #define HAVE_EXTATTR_SET_FD 1 #define HAVE_EXTATTR_SET_FILE 1 #define HAVE_SYS_ACL_H 1 From scottl at samsco.org Sat Apr 11 21:48:45 2009 From: scottl at samsco.org (Scott Long) Date: Sat Apr 11 21:48:52 2009 Subject: [Fwd: svn commit: r190949 - head/sys/vm] In-Reply-To: <49E11CE7.5050903@cs.rice.edu> References: <49E11CE7.5050903@cs.rice.edu> Message-ID: <49E172A3.2000108@samsco.org> Off the top of my head, I would almost expect this to conflict with Java. Haven't tried it, though, so I can't do anything more than speculate. However, I would encourage testing here. Scott Alan Cox wrote: > It's possible that this could cause problems for "exotic" languages that > do their own memory management, i.e., they don't use libc's malloc(). > If anyone experiences or hears of such things, please let me know so > that we can get the problems sorted out well before the 8.0 release. > > Alan > > > ------------------------------------------------------------------------ > > Subject: > svn commit: r190949 - head/sys/vm > From: > Alan Cox > Date: > Sat, 11 Apr 2009 22:34:09 +0000 (UTC) > To: > src-committers@freebsd.org, svn-src-all@freebsd.org, > svn-src-head@freebsd.org > > To: > src-committers@freebsd.org, svn-src-all@freebsd.org, > svn-src-head@freebsd.org > > > Author: alc > Date: Sat Apr 11 22:34:08 2009 > New Revision: 190949 > URL: http://svn.freebsd.org/changeset/base/190949 > > Log: > Remove execute permission from the memory allocated by sbrk(). > > Pre-announced on: -arch (3/31/09) > Discussed with: rwatson > Tested by: marius (sparc64) > > Modified: > head/sys/vm/vm_unix.c > > Modified: head/sys/vm/vm_unix.c > ============================================================================== > --- head/sys/vm/vm_unix.c Sat Apr 11 22:07:19 2009 (r190948) > +++ head/sys/vm/vm_unix.c Sat Apr 11 22:34:08 2009 (r190949) > @@ -117,7 +117,7 @@ obreak(td, uap) > goto done; > } > rv = vm_map_insert(&vm->vm_map, NULL, 0, old, new, > - VM_PROT_ALL, VM_PROT_ALL, 0); > + VM_PROT_RW, VM_PROT_ALL, 0); > if (rv != KERN_SUCCESS) { > error = ENOMEM; > goto done; > > > ------------------------------------------------------------------------ > > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" From alc at cs.rice.edu Sat Apr 11 21:58:15 2009 From: alc at cs.rice.edu (Alan Cox) Date: Sat Apr 11 21:58:22 2009 Subject: [Fwd: svn commit: r190949 - head/sys/vm] In-Reply-To: <49E172A3.2000108@samsco.org> References: <49E11CE7.5050903@cs.rice.edu> <49E172A3.2000108@samsco.org> Message-ID: <49E174DE.90603@cs.rice.edu> Scott Long wrote: > Off the top of my head, I would almost expect this to conflict with > Java. Haven't tried it, though, so I can't do anything more than > speculate. However, I would encourage testing here. > It doesn't. I verified that the Sun JVM works. Alan From james-freebsd-current at jrv.org Sat Apr 11 22:52:43 2009 From: james-freebsd-current at jrv.org (James R. Van Artsdalen) Date: Sat Apr 11 22:52:49 2009 Subject: can't boot 5.5 TB GPT disk Message-ID: <49E1819B.7000604@jrv.org> FreeBSD bigback.housenet.jrv 8.0-CURRENT FreeBSD 8.0-CURRENT #0 r190917: Sat Apr 11 19:48:25 CDT 2009 james@bigback.housenet.jrv:/usr/obj/usr/src/sys/GENERIC amd64 I can't boot a GPT partitioned 5.5 TB disc, where the UFS root partition is near the end of the disk. If I put another disk in the system and mount root from the GPT disk the system runs fine. The 5.5 TB disk is partitioned: bigback# gpart show => 34 11718748093 ad6 GPT (5.5T) 34 6 - free - (3.0K) 40 409600 1 efi (200M) 409640 11634190128 2 !6a898cc3-1dd2-11b2-99a6-080020736631 (5.4T) 11634599768 128 3 freebsd-boot (64K) 11634599896 4194304 4 freebsd-ufs (2.0G) 11638794200 33554432 5 freebsd-swap (16G) 11672348632 4194304 6 freebsd-ufs (2.0G) 11676542936 33554432 7 freebsd-ufs (16G) 11710097368 8388608 8 freebsd-ufs (4.0G) 11718485976 262151 - free - (128M) If I try to boot it (disk1 so pressing F5 here) it fails looking like this (there is no UART available so this is typed from a pic, with typos): F1 FreeBSD F5 Drive 1 Default: F1 BTX Loader 1.00 BTX version is 1.02 Consoles: internal video/keyboard BIOS drive C: is disk0 BIOS drive D: is disk1 BIOS 630kb/3136864kB available memory FreeBSD/i386 bootstrap loader, Revision 1.1 (james@bigback.housenet.jrv, Sat Apr 11 08:19:00 CDT 2009 \ can't load 'kernel' Type '?' for a list of commands, 'help' for more details OK To get this far suggests to me that PMBR and GPTBOOT worked, and that the problem is elsewhere. Suggestions? Could there be a 32-bit truncation lurking in a loader somewhere? PS. Note that the "lsdev' command causes the loader to crash while printing out the info on the big disk, right after the EFI line for ad6p1... From freebsd-listen at fabiankeil.de Sun Apr 12 08:03:48 2009 From: freebsd-listen at fabiankeil.de (Fabian Keil) Date: Sun Apr 12 08:42:41 2009 Subject: svn commit: r190857 - head/sys/dev/kbdmux In-Reply-To: <200904082052.n38KqU9p075633@svn.freebsd.org> References: <200904082052.n38KqU9p075633@svn.freebsd.org> Message-ID: <20090412170335.5a8a3169@fabiankeil.de> Maksim Yevmenkin wrote: > Author: emax > Date: Wed Apr 8 20:52:30 2009 > New Revision: 190857 > URL: http://svn.freebsd.org/changeset/base/190857 > > Log: > Undo SVN rev 183283 > > Do not use Giant for kbdmux(4) locking. This is wrong and apparently > causing more problems than it solves. This will re-open the issue > where interrupt handlers may race with kbdmux(4) in polling mode. > Typical symptoms include (but not limited to) duplicated and/or > missing characters when low level console functions (such as gets) > are used while interrupts are enabled (for example geli password > prompt, mountroot prompt etc.) > > MFC after: 3 days > > Modified: > head/sys/dev/kbdmux/kbdmux.c > > Modified: head/sys/dev/kbdmux/kbdmux.c > ============================================================================== > --- head/sys/dev/kbdmux/kbdmux.c Wed Apr 8 20:43:19 2009 (r190856) > +++ head/sys/dev/kbdmux/kbdmux.c Wed Apr 8 20:52:30 2009 (r190857) > @@ -104,10 +104,10 @@ MALLOC_DEFINE(M_KBDMUX, KEYBOARD_NAME, " > > #define KBDMUX_LOCK_DESTROY(s) > > -#define KBDMUX_LOCK(s) \ > - mtx_lock(&Giant) > -#define KBDMUX_UNLOCK(s) \ > - mtx_unlock(&Giant) > +#define KBDMUX_LOCK(s) > + > +#define KBDMUX_UNLOCK(s) > + > #define KBDMUX_LOCK_ASSERT(s, w) > > #define KBDMUX_SLEEP(s, f, d, t) \ How about turning this into a compile-time or sysctl option or at least mentioning the change in /usr/src/UPDATING? With this commit, providing the geli key phrase on boot is impossible on my AMD64 dual core system. Not even enabling the "visible characters" option helps because obviously backspace is broken too. Before theses locks were introduces I worked around the problem with this gets() hack (which forced me to reduce the key entropy): http://www.fabiankeil.de/sourcecode/freebsd/gets-no-duplicates.diff and now I will simply revert your commit locally, but I assume I'm not the only geli user who prefers to be able to boot the system without local patches. Fabian -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 196 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20090412/4e73f9db/signature.pgp From lists at jnielsen.net Sun Apr 12 09:48:39 2009 From: lists at jnielsen.net (John Nielsen) Date: Sun Apr 12 10:03:00 2009 Subject: ZFS/extattr lockup (was Re: bsdtar lockup on Current-03/10/2009) In-Reply-To: <49E16A89.3030108@freebsd.org> References: <200903100104.53847.ken__6247.10998167775$1236647281$gmane$org@mthelicon.com> <200903112229.41052.lists@jnielsen.net> <49E16A89.3030108@freebsd.org> Message-ID: <200904121248.36584.lists@jnielsen.net> On Sunday 12 April 2009 12:14:01 am Tim Kientzle wrote: > John Nielsen wrote: > > On Wednesday 11 March 2009 12:35:37 am Tim Kientzle wrote: > >> John Nielsen wrote: > >>> I today noticed the same problem on -CURRENT i386 built March 9. > >>> ... using ZFS and initially > >>> thought that was the source of the regression but I haven't > >>> produced the lockup with anything but tar and the extattr removal > >>> hack seems to have fixed it for now ... > >> > >> The common element so far seems to be ZFS. Can you verify that > >> > >> $ lsextattr -h user > >> > >> hangs on your system as well? That invokes the same > >> extattr_list_link system call used by tar to enumerate > >> the extended attributes on a file. > > > > Confirmed. I ran the command on a file in /root (UFS) with no > > problem. Running again on a file in /home/john (ZFS) caused the hang. > > John Baldwin committed a fix for the ZFS problem > (r189967, 2009-03-18 16:19:44UTC), so this should be fixed. > > Could you verify that lsextattr no longer hangs > the kernel after this point? > > Could you verify that re-enabling extended attribute > archiving in tar no longer hangs? > > I'd like to enable the extended attribute support > in tar for real if this is really fixed. Yes, I saw the commit and manually reverted libarchive to test on 3/20. I sent the post below but I don't know if it went through. Everything was solid then and has been since, so I think jhb's patch did the trick. JN ---------- Forwarded Message ---------- Subject: Re: repeatable ZFS panic: share->excl Date: Friday 20 March 2009 From: John Nielsen To: freebsd-current@freebsd.org On Wednesday 18 March 2009 12:09:18 pm John Baldwin wrote: > On Tuesday 17 March 2009 3:04:40 am Pawel Jakub Dawidek wrote: > > On Fri, Mar 13, 2009 at 02:08:03PM -0400, John Baldwin wrote: > > > John Baldwin wrote: > > > >Yes, I think that is the real bug. Looking at this further I > > > > think zfs_get_xattrdir() will return the vnode locked if it has > > > > to create a new node via zfs_make_attrdir() but only returns it > > > > held and unlocked if it finds an existing one. So my new patch > > > > is to just fix zfs_get_xattrdir() to unlock the vnode if it > > > > creates a new one like so: > > > > > > > >(Sorry, TBird is probably going to butcher all the whitespace): > > > > > > > >--- > > > >//depot/user/jhb/lock/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_d > >ir.c > > > > > >+++ > > > >/Users/jhb/work/p4/lock/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs > >_dir.c > > > > > >@@ -940,6 +940,7 @@ > > > > /* NB: we already did dmu_tx_wait() if necessary */ > > > > goto top; > > > > } > > > >+ VOP_UNLOCK(*xvpp, 0); > > > > > > > > return (error); > > > > } > > > > > > > >A non-butchered version is at > > > > www.FreeBSD.org/~jhb/patches/zfs_ea.patch. > > > > > > So lulf@ reports success with this patch. Pawel, can you review > > > it? > > > > Yes, it works for me too and looks good. The only thing we need to > > change is to check for error beeing 0 before unlocking the vnode. > > The zfs_make_xattrdir() function can still return with EIO, so I'd > > add something like this: > > > > if (error == 0) > > VOP_UNLOCK(*xvpp, 0); > > Yes, I realized this about 30 minutes after I sent this e-mail. :-P I > will commit a version with the error check today. > > > Thank you John for spending time on tracking this one down. > > Sure, was good to read a bit of the ZFS code. I had a chance to test this patch today and it looks good. Which is to say my system hasn't hung yet. :) I built world from 3/19 -HEAD and was able to "lsextattr -h user" on files on a ZFS without any ill effects. I un-patched libarchive (so it uses extended attributes again) and rebuilt and reinstalled it and bsdtar and was able to do portupgrades normally. Thanks to all involved. JN ------------------------------------------------------- From emax at freebsd.org Sun Apr 12 10:30:54 2009 From: emax at freebsd.org (Maksim Yevmenkin) Date: Sun Apr 12 11:00:44 2009 Subject: svn commit: r190857 - head/sys/dev/kbdmux In-Reply-To: <20090412170335.5a8a3169@fabiankeil.de> References: <200904082052.n38KqU9p075633@svn.freebsd.org> <20090412170335.5a8a3169@fabiankeil.de> Message-ID: On Sun, Apr 12, 2009 at 8:03 AM, Fabian Keil wrote: > Maksim Yevmenkin wrote: > >> Author: emax >> Date: Wed Apr ?8 20:52:30 2009 >> New Revision: 190857 >> URL: http://svn.freebsd.org/changeset/base/190857 >> >> Log: >> ? Undo SVN rev 183283 >> >> ? Do not use Giant for kbdmux(4) locking. This is wrong and apparently >> ? causing more problems than it solves. This will re-open the issue >> ? where interrupt handlers may race with kbdmux(4) in polling mode. >> ? Typical symptoms include (but not limited to) duplicated and/or >> ? missing characters when low level console functions (such as gets) >> ? are used while interrupts are enabled (for example geli password >> ? prompt, mountroot prompt etc.) >> >> ? MFC after: ?3 days >> >> Modified: >> ? head/sys/dev/kbdmux/kbdmux.c [...] > How about turning this into a compile-time or sysctl option > or at least mentioning the change in /usr/src/UPDATING? i do not believe that compile-time nor sysctl option is the right choice here as it is never allowed to use locks in low-level keyboard drivers. entry in UPDATING is probably a good idea. > With this commit, providing the geli key phrase on > boot is impossible on my AMD64 dual core system. right, i really hate to say this, but the amount of bug reports, lor's etc.that were submitted after this change is far more (imo) than amount of people that ran relatively uncommon setup with encrypted root (which, btw, prompted the original commit). of course, there is no question, it has to be fixed. > Not even enabling the "visible characters" option helps > because obviously backspace is broken too. if you do not need kbdmix(4) you might just want to disable it on your system. i think it should help with your particular problem. > Before theses locks were introduces I worked around the problem > with this gets() hack (which forced me to reduce the key entropy): > http://www.fabiankeil.de/sourcecode/freebsd/gets-no-duplicates.diff > and now I will simply revert your commit locally, but I assume I'm > not the only geli user who prefers to be able to boot the system > without local patches. if your primary keyboard is atkbd(4), you might want to try the following patch. it is completely untested (i did not even compile it), so be warned ... Index: atkbd.c =================================================================== --- atkbd.c (revision 190905) +++ atkbd.c (working copy) @@ -476,7 +476,7 @@ static int atkbd_intr(keyboard_t *kbd, void *arg) { - atkbd_state_t *state; + atkbd_state_t *state = (atkbd_state_t *)kbd->kb_data; int delay[2]; int c; @@ -485,7 +485,6 @@ * The keyboard was not detected before; * it must have been reconnected! */ - state = (atkbd_state_t *)kbd->kb_data; init_keyboard(state->kbdc, &kbd->kb_type, kbd->kb_config); KBD_FOUND_DEVICE(kbd); @@ -497,6 +496,9 @@ } if (KBD_IS_ACTIVE(kbd) && KBD_IS_BUSY(kbd)) { + if (state->ks_polling) + return 0; + /* let the callback function to process the input */ (*kbd->kb_callback.kc_func)(kbd, KBDIO_KEYINPUT, kbd->kb_callback.kc_arg); thanks, max From matheus at eternamente.info Sun Apr 12 12:19:00 2009 From: matheus at eternamente.info (Nenhum_de_Nos) Date: Sun Apr 12 13:13:27 2009 Subject: ata and seagate microdrive problems In-Reply-To: References: Message-ID: <4c84392f51488148040ecc5e99c9971b.squirrel@cygnus.homeunix.com> On Sat, April 11, 2009 15:29, Warren Block wrote: > On Thu, April 9, 2009 19:48, Nenhum_de_Nos wrote: >> >> I'm trying to install current on via itx using ide 44pin to cf >> adapter and a seagate 8GB microdrive. >> >> I thought it was to be ok, but just today when I received the adapter >> I got nowhere in this. I tried 7.1-STABLE and 8.0-CURRENT from >> 200902, and both fail to find it. the same thing in 7.1R. > > "Fail to find it" is a little vague. Is the CF card detected by the > BIOS? my bad, I forgot to say that. bios finds ok, I can install OpenBSD on it no problem. > Many CF-to-IDE adapters don't support DMA: > > http://lists.freebsd.org/pipermail/freebsd-small/2005-July/000441.html > > Lack of DMA support in the adapter results in errors, lots of them, > after the kernel boots. Disabling DMA as above fixed that on a 2G CF > card and CF-to-IDE adapter for me. I dit that. on 7.1R, and snapshots from stable and current from 200902. also tried hw.ata.ata_dma_check_80pin=0 on all, nothing. thanks for your input :) matheus > -Warren Block * Rapid City, South Dakota USA > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > -- We will call you cygnus, The God of balance you shall be From kabaev at gmail.com Sun Apr 12 13:11:16 2009 From: kabaev at gmail.com (Alexander Kabaev) Date: Sun Apr 12 13:31:08 2009 Subject: svn commit: r190857 - head/sys/dev/kbdmux In-Reply-To: References: <200904082052.n38KqU9p075633@svn.freebsd.org> <20090412170335.5a8a3169@fabiankeil.de> Message-ID: <20090412154413.1e250cc7@kan.dnsalias.net> On Sun, 12 Apr 2009 10:00:35 -0700 Maksim Yevmenkin wrote: > On Sun, Apr 12, 2009 at 8:03 AM, Fabian Keil > > > How about turning this into a compile-time or sysctl option > > or at least mentioning the change in /usr/src/UPDATING? > > i do not believe that compile-time nor sysctl option is the right > choice here as it is never allowed to use locks in low-level keyboard > drivers. entry in UPDATING is probably a good idea. > > > With this commit, providing the geli key phrase on > > boot is impossible on my AMD64 dual core system. > > right, i really hate to say this, but the amount of bug reports, lor's > etc.that were submitted after this change is far more (imo) than > amount of people that ran relatively uncommon setup with encrypted > root (which, btw, prompted the original commit). of course, there is > no question, it has to be fixed. This also affects DDB prompts, correct? What is the timeframe for fixing this? -- Alexander Kabaev -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 188 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20090412/02f8feae/signature.pgp From marcus at FreeBSD.org Sun Apr 12 13:37:56 2009 From: marcus at FreeBSD.org (Joe Marcus Clarke) Date: Sun Apr 12 14:32:23 2009 Subject: Hal and KDM breakage (was Re: KDE4 and input events stalled) In-Reply-To: <49DE86EF.3030409@FreeBSD.org> References: <934e1d760904061455o4736d643o1d07e3292192d94c@mail.gmail.com> <1239078081.1908.41.camel@balrog.2hip.net> <49DAE987.7090802@freebsd.org> <1239086408.35025.59.camel@shumai.marcuscom.com> <20090407185915.GY31409@albert.catwhisker.org> <49DBA371.3080804@freebsd.org> <92cd2ff70904071637h362da63ua13c1f8eca6fc616@mail.gmail.com> <1239147806.98664.12.camel@shumai.marcuscom.com> <92cd2ff70904071653r4bf3b381lf5de220b2e280c0c@mail.gmail.com> <1239150469.98664.18.camel@shumai.marcuscom.com> <49DC405B.7090208@freebsd.org> <49DE86EF.3030409@FreeBSD.org> Message-ID: <1239568682.19630.48.camel@shumai.marcuscom.com> On Thu, 2009-04-09 at 16:38 -0700, Doug Barton wrote: > Not sure if this is even possible, but I thought I'd throw it out > there. Would starting hald before ttys are loaded, then restarting it > again at the end of the boot process work to solve this issue? It > seems that you have 2 distinct 'flavors' of hald here (with vty > support, and without), so if it's smart enough to do the right thing > for its consumers when it is restarted I think this approach might work. Yes, this should work. If you modify hald's rc.d script to start immediately, then restart itself based on the getty delay already present, I believe both X and device management will work. Joe -- Joe Marcus Clarke FreeBSD GNOME Team :: gnome@FreeBSD.org FreeNode / #freebsd-gnome http://www.FreeBSD.org/gnome -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: This is a digitally signed message part Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20090412/be34e020/attachment.pgp From mav at FreeBSD.org Sun Apr 12 14:07:39 2009 From: mav at FreeBSD.org (Alexander Motin) Date: Sun Apr 12 14:44:00 2009 Subject: AMD 780G chipset major issues 1/3 (ata, ataati) In-Reply-To: <83e5fb980904101726m54af3a4boe875854b7e9bd11e@mail.gmail.com> References: <1239063789.00097213.1239052203@10.7.7.3> <49DBAEB5.7010500@FreeBSD.org> <20090407200257.GB19850@home.opsec.eu> <49DBB3C0.9010800@FreeBSD.org> <83e5fb980904071402k600cbc09hcde8994cb5465f52@mail.gmail.com> <49DC6129.4070107@FreeBSD.org> <83e5fb980904101726m54af3a4boe875854b7e9bd11e@mail.gmail.com> Message-ID: <49E25818.1090600@FreeBSD.org> Diego Depaoli wrote: > On Wed, Apr 8, 2009 at 10:32 AM, Alexander Motin wrote: >> You can try to comment out 'ctlr->channels = 1;' line in your ata-ati.c >> file to allow second channel of the second controller to be attached. > I'm sorry, did not help. You haven't got second channel or it does not work? -- Alexander Motin From emax at freebsd.org Sun Apr 12 14:53:44 2009 From: emax at freebsd.org (Maksim Yevmenkin) Date: Sun Apr 12 15:48:46 2009 Subject: svn commit: r190857 - head/sys/dev/kbdmux In-Reply-To: <20090412154413.1e250cc7@kan.dnsalias.net> References: <200904082052.n38KqU9p075633@svn.freebsd.org> <20090412170335.5a8a3169@fabiankeil.de> <20090412154413.1e250cc7@kan.dnsalias.net> Message-ID: On Sun, Apr 12, 2009 at 12:44 PM, Alexander Kabaev wrote: > On Sun, 12 Apr 2009 10:00:35 -0700 > Maksim Yevmenkin wrote: > >> On Sun, Apr 12, 2009 at 8:03 AM, Fabian Keil >> >> > How about turning this into a compile-time or sysctl option >> > or at least mentioning the change in /usr/src/UPDATING? >> >> i do not believe that compile-time nor sysctl option is the right >> choice here as it is never allowed to use locks in low-level keyboard >> drivers. entry in UPDATING is probably a good idea. >> >> > With this commit, providing the geli key phrase on >> > boot is impossible on my AMD64 dual core system. >> >> right, i really hate to say this, but the amount of bug reports, lor's >> etc.that were submitted after this change is far more (imo) than >> amount of people that ran relatively uncommon setup with encrypted >> root (which, btw, prompted the original commit). of course, there is >> no question, it has to be fixed. > > This also affects DDB prompts, correct? What is the timeframe for > fixing this? not really, imo. in ddb prompts interrupts are disabled (as i understand it). as far as fixing it, it could be as simple as the patch i sent in my previous email. thanks, max From trebestie at gmail.com Sun Apr 12 14:58:06 2009 From: trebestie at gmail.com (Diego Depaoli) Date: Sun Apr 12 15:49:28 2009 Subject: AMD 780G chipset major issues 1/3 (ata, ataati) In-Reply-To: <49E25818.1090600@FreeBSD.org> References: <1239063789.00097213.1239052203@10.7.7.3> <49DBAEB5.7010500@FreeBSD.org> <20090407200257.GB19850@home.opsec.eu> <49DBB3C0.9010800@FreeBSD.org> <83e5fb980904071402k600cbc09hcde8994cb5465f52@mail.gmail.com> <49DC6129.4070107@FreeBSD.org> <83e5fb980904101726m54af3a4boe875854b7e9bd11e@mail.gmail.com> <49E25818.1090600@FreeBSD.org> Message-ID: <83e5fb980904121458s37bb3f52w54a0be23563e1006@mail.gmail.com> Apparently I got no changes. On 4/12/09, Alexander Motin wrote: > Diego Depaoli wrote: >> On Wed, Apr 8, 2009 at 10:32 AM, Alexander Motin wrote: >>> You can try to comment out 'ctlr->channels = 1;' line in your ata-ati.c >>> file to allow second channel of the second controller to be attached. >> I'm sorry, did not help. > > You haven't got second channel or it does not work? > > -- > Alexander Motin > -- Diego Depaoli From kabaev at gmail.com Sun Apr 12 15:02:10 2009 From: kabaev at gmail.com (Alexander Kabaev) Date: Sun Apr 12 15:56:51 2009 Subject: svn commit: r190857 - head/sys/dev/kbdmux In-Reply-To: References: <200904082052.n38KqU9p075633@svn.freebsd.org> <20090412170335.5a8a3169@fabiankeil.de> <20090412154413.1e250cc7@kan.dnsalias.net> Message-ID: <20090412180159.659d9195@kan.dnsalias.net> On Sun, 12 Apr 2009 14:53:41 -0700 Maksim Yevmenkin wrote: > On Sun, Apr 12, 2009 at 12:44 PM, Alexander Kabaev > wrote: > > On Sun, 12 Apr 2009 10:00:35 -0700 > > Maksim Yevmenkin wrote: > > > > not really, imo. in ddb prompts interrupts are disabled (as i > understand it). > > as far as fixing it, it could be as simple as the patch i sent in my > previous email. > > thanks, > max Thanks. The situation is a whole lot better than what I was imagining then. -- Alexander Kabaev -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 188 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20090412/77eca481/signature.pgp From yanefbsd at gmail.com Sun Apr 12 15:28:56 2009 From: yanefbsd at gmail.com (Garrett Cooper) Date: Sun Apr 12 16:02:48 2009 Subject: [Fwd: svn commit: r190949 - head/sys/vm] In-Reply-To: <49E174DE.90603@cs.rice.edu> References: <49E11CE7.5050903@cs.rice.edu> <49E172A3.2000108@samsco.org> <49E174DE.90603@cs.rice.edu> Message-ID: <7d6fde3d0904121506u5ed82765oe6fd73231f4c6b97@mail.gmail.com> On Sat, Apr 11, 2009 at 9:58 PM, Alan Cox wrote: > Scott Long wrote: >> >> Off the top of my head, I would almost expect this to conflict with >> Java. ?Haven't tried it, though, so I can't do anything more than >> speculate. ?However, I would encourage testing here. >> > > It doesn't. ?I verified that the Sun JVM works. Has this been verified with Perl / Python yet? -Garrett From trebestie at gmail.com Sun Apr 12 17:07:42 2009 From: trebestie at gmail.com (Diego Depaoli) Date: Sun Apr 12 17:27:49 2009 Subject: AMD 780G chipset major issues 1/3 (ata, ataati) In-Reply-To: <83e5fb980904121458s37bb3f52w54a0be23563e1006@mail.gmail.com> References: <1239063789.00097213.1239052203@10.7.7.3> <49DBAEB5.7010500@FreeBSD.org> <20090407200257.GB19850@home.opsec.eu> <49DBB3C0.9010800@FreeBSD.org> <83e5fb980904071402k600cbc09hcde8994cb5465f52@mail.gmail.com> <49DC6129.4070107@FreeBSD.org> <83e5fb980904101726m54af3a4boe875854b7e9bd11e@mail.gmail.com> <49E25818.1090600@FreeBSD.org> <83e5fb980904121458s37bb3f52w54a0be23563e1006@mail.gmail.com> Message-ID: <83e5fb980904121707s18b0a74bveb6294490935be89@mail.gmail.com> Loading ata-ati, even ata-siliconimage is loaded. It's right? On 4/12/09, Diego Depaoli wrote: > Apparently I got no changes. > > On 4/12/09, Alexander Motin wrote: >> Diego Depaoli wrote: >>> On Wed, Apr 8, 2009 at 10:32 AM, Alexander Motin >>> wrote: >>>> You can try to comment out 'ctlr->channels = 1;' line in your ata-ati.c >>>> file to allow second channel of the second controller to be attached. >>> I'm sorry, did not help. >> >> You haven't got second channel or it does not work? >> >> -- >> Alexander Motin >> > > > -- > Diego Depaoli > -- Diego Depaoli From ben at wanderview.com Sun Apr 12 18:34:38 2009 From: ben at wanderview.com (Ben Kelly) Date: Sun Apr 12 19:26:36 2009 Subject: comparing svn and cvs somewhat In-Reply-To: <49D8EC20.70700@telenix.org> References: <49D8EC20.70700@telenix.org> Message-ID: On Apr 5, 2009, at 1:36 PM, Chuck Robey wrote: > I have gotten a local copy of the svn repo going on my home here, by > using > svnsync, which seems (by what I've read and been told) to be the > right method. > I'm wondering about a feature that is there for cvs, in cvsup, but > which seems > to be missing in svnsync for svn. > > What I'm after is a much better way to maintain a local repo than > what I'm > seeing now in maintaining my svn repo, with svnsync. The main > feature that I > think I'm missing is the ability to be able to compare files on a > central server > (something serving all FreeBSDers) to files on everybody's personal > repo, and > to automatically update them if there isn't a perfect comparison. > I'm not > talking about the varying ways that your repo might get damaged, but > I think > that svnsync only knows that you have a particular revision number, > not that the > file is correct. If your repo gets damage, I think that nothing > exists to > automatically fix it. > > So, if this feature IS something that's already available in svn, > I'd like to > here a summary of what tool to use the how to do it, so I can verify > myself that > what I'm thinking about already exists. That'd free me to begin > writing > software, to see if I could implement such a feature. I'm not truly > certain of > this, but it seems to me that implementing such a feature, using > something like > Python, would be very easy to do. Could end up with a svn version > of cvs's > cvsup. Maybe, call it svnup? I'm terrible at names, if you think > that name > makes no sense, please, tell me so. I looked into this a bit previously. I wanted something similar to cvsup to help me track remote repositories as vendor branches in my local repository. My initial research showed some feature requests for "svn export -r REV" which would have done most of this for me. Unfortunately the last time I looked it hadn't been implemented. So based on that I wrote a very-alpha proof of concept script you can find here: http://www.wanderview.com/svn/public/svnsnap/0.1/ Please use at your own risk because its only been tested very lightly. I've pretty much abandoned this script because I don't think a shell script wrapper can handle all the corner cases with the current support in the svn tools. In particular I know this script does not handle updates to file and directory permissions. I started working on a C utility that interfaced directly with the svn API's, but I got distracted by real life before getting it in working order. Anyway, I'm interested in a tool like this, but I doubt I will have a lot of time in the short term to work on it. Hope that helps. - Ben From sean.bruno at dsl-only.net Sun Apr 12 22:06:47 2009 From: sean.bruno at dsl-only.net (Sean Bruno) Date: Sun Apr 12 23:05:10 2009 Subject: NFS errors on compile of -current Message-ID: <1239599205.24831.3.camel@localhost.localdomain> [sean@bsd64 ~/bsd/head/sys/amd64/compile/SBP_TARG]$ make linking kernel.debug nfs_srvsubs.o(.text+0xd0c): In function `nfsrv_modevent': ../../../nfsserver/nfs_srvsubs.c:560: undefined reference to `nfsd_call_nfsserver' nfs_srvsubs.o(.text+0xd42):../../../nfsserver/nfs_srvsubs.c:569: undefined reference to `nfsd_call_nfsserver' *** Error code 1 Stop in /usr/home/sean/bsd/head/sys/amd64/compile/SBP_TARG. From dominique.goncalves at gmail.com Mon Apr 13 02:30:39 2009 From: dominique.goncalves at gmail.com (Dominique Goncalves) Date: Mon Apr 13 03:14:18 2009 Subject: Unusable Xorg with USB mouse Message-ID: <7daacbbe0904130203m62080028v14f6a1e4a3285dc0@mail.gmail.com> Hi, I upgraded my FreeBSD desktop (XFCE4 and some applications) from 7.1-RELEASE to 8.0-CURRENT r190942 all ports was build from scratch after removing old files with make delete-old delete-old-libs. Now it's very hard to listen music with mplayer, write text with vim, browse internet with firefox... it just stop working and restart when moving the mouse! Let me know if you need more information. Any help is really appreciated, Thanks. > dmesg Copyright (c) 1992-2009 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 is a registered trademark of The FreeBSD Foundation. FreeBSD 8.0-CURRENT #0 r190942: Sat Apr 11 22:05:48 CEST 2009 root@djdomics:/usr/obj/usr/src/sys/GENERIC_NODEBUG Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel(R) Pentium(R) 4 CPU 2.00GHz (2000.15-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0xf24 Stepping = 4 Features=0x3febfbff real memory = 805306368 (768 MB) avail memory = 774045696 (738 MB) ACPI APIC Table: MADT: Forcing active-low polarity and level trigger for SCI ioapic0 irqs 0-23 on motherboard kbd1 at kbdmux0 acpi0: on motherboard acpi0: [ITHREAD] acpi0: Power Button (fixed) Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x808-0x80b on acpi0 acpi_button0: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 agp0: on hostb0 pcib1: at device 1.0 on pci0 pci1: on pcib1 vgapci0: mem 0xde000000-0xdeffffff,0xc0000000-0xcfffffff irq 16 at device 0.0 on pci1 isab0: at device 2.0 on pci0 isa0: on isab0 atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xff00-0xff0f at device 2.5 on pci0 ata0: on atapci0 ata0: [ITHREAD] ata1: on atapci0 ata1: [ITHREAD] ohci0: mem 0xdfffc000-0xdfffcfff irq 20 at device 3.0 on pci0 ohci0: [ITHREAD] usbus0: on ohci0 ohci1: mem 0xdfffd000-0xdfffdfff irq 21 at device 3.1 on pci0 ohci1: [ITHREAD] usbus1: on ohci1 ohci2: mem 0xdfffe000-0xdfffefff irq 22 at device 3.2 on pci0 ohci2: [ITHREAD] usbus2: on ohci2 ehci0: mem 0xdffff000-0xdfffffff irq 23 at device 3.3 on pci0 ehci0: [ITHREAD] usbus3: EHCI version 1.0 usbus3: on ehci0 pcm0: port 0xdc00-0xdc1f,0xd800-0xd80f,0xd400-0xd40f,0xd000-0xd03f irq 19 at device 8.0 on pci0 pcm0: [ITHREAD] pcm0: system configuration SubVendorID: 0x1412, SubDeviceID: 0xd63b XIN2 Clock Source: 22.5792MHz(44.1kHz*512) MPU-401 UART(s) #: 1 AC'97 codec: not exist ADC #: 4 DAC #: 4 Multi-track converter type: I2S(96KHz support, 24bit resolution, ID#0x2) S/PDIF(IN/OUT): 1/1 ID# 0x00 GPIO(mask/dir/state): 0x04/0xfb/0x7e rl0: port 0xcc00-0xccff mem 0xdfffbf00-0xdfffbfff irq 18 at device 11.0 on pci0 miibus0: on rl0 rlphy0: PHY 0 on miibus0 rlphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto rl0: Ethernet address: 00:10:dc:82:9b:d2 rl0: [ITHREAD] atrtc0: port 0x70-0x71 irq 8 on acpi0 fdc1: port 0x3f2-0x3f3,0x3f4-0x3f5,0x3f7 irq 6 drq 2 on acpi0 fdc1: [FILTER] uart0: <16550 or compatible> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 uart0: [FILTER] uart1: <16550 or compatible> port 0x2f8-0x2ff irq 3 on acpi0 uart1: [FILTER] ppc0: port 0x378-0x37f irq 7 on acpi0 ppc0: Generic chipset (EPP/NIBBLE) in COMPATIBLE mode ppc0: [ITHREAD] ppbus0: on ppc0 plip0: on ppbus0 plip0: [ITHREAD] lpt0: on ppbus0 lpt0: [ITHREAD] lpt0: Interrupt-driven port ppi0: on ppbus0 cpu0: on acpi0 p4tcc0: on cpu0 pmtimer0 on isa0 orm0: at iomem 0xc0000-0xcffff,0xd0000-0xd27ff pnpid ORM0000 on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 atkbdc0: at port 0x60,0x64 on isa0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] atkbd0: [ITHREAD] fdc0: No FDOUT register! Timecounter "TSC" frequency 2000150592 Hz quality 800 Timecounters tick every 1.000 msec usbus0: 12Mbps Full Speed USB v1.0 usbus1: 12Mbps Full Speed USB v1.0 usbus2: 12Mbps Full Speed USB v1.0 usbus3: 480Mbps High Speed USB v2.0 ad0: 57241MB at ata0-master UDMA100 ugen0.1: at usbus0 uhub0: on usbus0 ugen1.1: at usbus1 uhub1: on usbus1 ugen2.1: at usbus2 uhub2: on usbus2 ugen3.1: at usbus3 uhub3: on usbus3 ad1: 57241MB at ata0-slave UDMA100 uhub0: 2 ports with 2 removable, self powered uhub1: 2 ports with 2 removable, self powered uhub2: 2 ports with 2 removable, self powered acd0: DVDROM at ata1-master UDMA33 GEOM: ad0: partition 1 does not start on a track boundary. GEOM: ad0: partition 1 does not end on a track boundary. acd1: CDRW at ata1-slave UDMA33 GEOM: ad0s2: geometry does not match label (255h,63s != 16h,255s). GEOM: ad1: partition 1 does not start on a track boundary. GEOM: ad1: partition 1 does not end on a track boundary. uhub3: 6 ports with 6 removable, self powered acd1: FAILURE - INQUIRY ILLEGAL REQUEST asc=0x24 ascq=0x00 acd0: FAILURE - INQUIRY ILLEGAL REQUEST asc=0x24 ascq=0x00 cd0 at ata1 bus 0 target 1 lun 0 cd0: Removable CD-ROM SCSI-0 device cd0: 33.000MB/s transfers cd0: cd present [196100 x 2048 byte records] cd1 at ata1 bus 0 target 0 lun 0 cd1: Removable CD-ROM SCSI-0 device cd1: 33.000MB/s transfers cd1: cd present [3510947 x 2048 byte records] GEOM_LABEL: Label for provider acd0 is iso9660/DIE_HARD_1. GEOM_LABEL: Label for provider ad0s2a is ufsid/47fa91abbef03a13. GEOM_LABEL: Label for provider ad0s2d is ufsid/47fa91ad7b28768a. GEOM_LABEL: Label for provider ad0s2e is ufsid/47fa91abefc1e226. GEOM_LABEL: Label for provider ad0s2f is ufsid/47fa91abfb5c1768. GEOM: ad1s2: geometry does not match label (255h,63s != 16h,255s). GEOM: ad1s3: geometry does not match label (16h,63s != 16h,255s). ugen2.2: at usbus2 ums0: on usbus2 ums0: 3 buttons and [XYZ] coordinates ID=0 GEOM_LABEL: Label for provider acd1 is iso9660/CDROM. GEOM_LABEL: Label for provider ad1s2a is ufsid/423b25e8c0bf6015. GEOM_LABEL: Label for provider ad1s2d is ufsid/423b25e933d9f5b1. GEOM_LABEL: Label for provider ad1s2e is ufsid/423b25e88d1a575d. GEOM_LABEL: Label for provider ad1s2f is ufsid/423b25e8f04b19a7. GEOM_LABEL: Label for provider ad1s3g is ufsid/423de7c40ececa0b. GEOM_LABEL: Label for provider ad1s3i is ufsid/423de7c57cc3c44b. GEOM_LABEL: Label for provider ad1s3j is ufsid/423de7cf5ab394ca. acd1: FAILURE - READ_BIG ILLEGAL REQUEST asc=0x64 ascq=0x00 Trying to mount root from ufs:/dev/ad0s2a GEOM_LABEL: Label ufsid/47fa91abbef03a13 removed. GEOM_LABEL: Label for provider ad0s2a is ufsid/47fa91abbef03a13. GEOM_LABEL: Label ufsid/47fa91abefc1e226 removed. GEOM_LABEL: Label for provider ad0s2e is ufsid/47fa91abefc1e226. GEOM_LABEL: Label ufsid/47fa91abfb5c1768 removed. GEOM_LABEL: Label for provider ad0s2f is ufsid/47fa91abfb5c1768. GEOM_LABEL: Label ufsid/47fa91ad7b28768a removed. GEOM_LABEL: Label for provider ad0s2d is ufsid/47fa91ad7b28768a. GEOM_LABEL: Label ufsid/47fa91abbef03a13 removed. GEOM_LABEL: Label ufsid/47fa91abefc1e226 removed. GEOM_LABEL: Label ufsid/47fa91abfb5c1768 removed. GEOM_LABEL: Label ufsid/47fa91ad7b28768a removed. rl0: link state changed to UP > vmstat -i interrupt total rate irq1: atkbd0 1823 1 irq14: ata0 10943 7 irq15: ata1 4692 3 irq18: rl0 32566 22 irq19: pcm0 99133 68 irq22: ohci2 31197 21 irq23: ehci0 2 0 cpu0: timer 2872088 1998 Total 3052444 2124 > cat /etc/rc.conf # -- sysinstall generated deltas -- # Mon Apr 7 23:50:43 2008 # Created: Mon Apr 7 23:50:43 2008 # Enable network daemons for user convenience. # Please make all changes to this file, not to /etc/defaults/rc.conf. # This file now contains just the overrides from /etc/defaults/rc.conf. hostname="djdomics" ifconfig_rl0="DHCP" keymap="fr.iso.acc" sshd_enable="YES" gnome_enable="YES" > cat /etc/X11/xorg.conf Section "ServerLayout" Identifier "X.org Configured" Screen 0 "Screen0" 0 0 InputDevice "Mouse0" "CorePointer" InputDevice "Keyboard0" "CoreKeyboard" Option "AllowEmptyInput" "off" EndSection Section "Files" ModulePath "/usr/local/lib/xorg/modules" FontPath "/usr/local/lib/X11/fonts/misc/" FontPath "/usr/local/lib/X11/fonts/TTF/" FontPath "/usr/local/lib/X11/fonts/OTF" FontPath "/usr/local/lib/X11/fonts/Type1/" FontPath "/usr/local/lib/X11/fonts/100dpi/" FontPath "/usr/local/lib/X11/fonts/75dpi/" EndSection Section "Module" Load "dbe" Load "dri" Load "extmod" Load "glx" Load "record" Load "xtrap" Load "freetype" EndSection Section "InputDevice" Identifier "Keyboard0" Driver "kbd" Option "XkbLayout" "fr" EndSection Section "InputDevice" Identifier "Mouse0" Driver "mouse" Option "Protocol" "auto" Option "Device" "/dev/sysmouse" Option "ZAxisMapping" "4 5 6 7" EndSection Section "Monitor" #DisplaySize 320 240 # mm Identifier "Monitor0" VendorName "FUS" ModelName "C700" HorizSync 30.0 - 72.0 VertRefresh 50.0 - 160.0 Option "DPMS" EndSection Section "Device" ### Available Driver options are:- ### Values: : integer, : float, : "True"/"False", ### : "String", : " Hz/kHz/MHz" ### [arg]: arg optional #Option "SWcursor" # [] #Option "HWcursor" # [] #Option "NoAccel" # [] #Option "ShadowFB" # [] #Option "UseFBDev" # [] #Option "Rotate" # [] #Option "VideoKey" # #Option "FlatPanel" # [] #Option "FPDither" # [] #Option "CrtcNumber" # #Option "FPScale" # [] #Option "FPTweak" # #Option "DualHead" # [] Identifier "Card0" Driver "nv" VendorName "nVidia Corporation" BoardName "NV36 [GeForce FX 5700LE]" BusID "PCI:1:0:0" EndSection Section "Screen" Identifier "Screen0" Device "Card0" Monitor "Monitor0" SubSection "Display" Viewport 0 0 Depth 1 EndSubSection SubSection "Display" Viewport 0 0 Depth 4 EndSubSection SubSection "Display" Viewport 0 0 Depth 8 EndSubSection SubSection "Display" Viewport 0 0 Depth 15 EndSubSection SubSection "Display" Viewport 0 0 Depth 16 EndSubSection SubSection "Display" Viewport 0 0 Depth 24 EndSubSection EndSection -- There's this old saying: "Give a man a fish, feed him for a day. Teach a man to fish, feed him for life." From rhurlin at gwdg.de Mon Apr 13 05:55:19 2009 From: rhurlin at gwdg.de (Rainer Hurling) Date: Mon Apr 13 06:38:47 2009 Subject: Unusable Xorg with USB mouse In-Reply-To: <7daacbbe0904130203m62080028v14f6a1e4a3285dc0@mail.gmail.com> References: <7daacbbe0904130203m62080028v14f6a1e4a3285dc0@mail.gmail.com> Message-ID: <49E3362B.9040704@gwdg.de> Hi Dominique, On 13.04.2009 11:03 (UTC+1), Dominique Goncalves wrote: > Hi, > > I upgraded my FreeBSD desktop (XFCE4 and some applications) from > 7.1-RELEASE to 8.0-CURRENT r190942 all ports was build from scratch > after removing old files with make delete-old delete-old-libs. as far as I know 'make delete-old delete-old-libs' has to be done from /usr/src and so it removes obsolete files from system (see /usr/src/ObsoleteFiles.inc). To remove ports (/usr/ports) and build from scratch you have to 'pkg_delete -a' or something like this... > Now it's very hard to listen music with mplayer, write text with vim, > browse internet with firefox... it just stop working and restart when > moving the mouse! There had been many changes in CURRENT and xorg in the last time. USB is totally new, libusb is integrated in the system (please do not install that port!) etc. So please read /usr/ports/UPDATING, especially the entries 20090309 and 20090123. Hope I could help, Rainer > Let me know if you need more information. > > Any help is really appreciated, > Thanks. > >> dmesg > Copyright (c) 1992-2009 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 is a registered trademark of The FreeBSD Foundation. > FreeBSD 8.0-CURRENT #0 r190942: Sat Apr 11 22:05:48 CEST 2009 > root@djdomics:/usr/obj/usr/src/sys/GENERIC_NODEBUG > Timecounter "i8254" frequency 1193182 Hz quality 0 > CPU: Intel(R) Pentium(R) 4 CPU 2.00GHz (2000.15-MHz 686-class CPU) > Origin = "GenuineIntel" Id = 0xf24 Stepping = 4 > Features=0x3febfbff > real memory = 805306368 (768 MB) > avail memory = 774045696 (738 MB) > ACPI APIC Table: > MADT: Forcing active-low polarity and level trigger for SCI > ioapic0 irqs 0-23 on motherboard > kbd1 at kbdmux0 > acpi0: on motherboard > acpi0: [ITHREAD] > acpi0: Power Button (fixed) > Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 > acpi_timer0: <24-bit timer at 3.579545MHz> port 0x808-0x80b on acpi0 > acpi_button0: on acpi0 > pcib0: port 0xcf8-0xcff on acpi0 > pci0: on pcib0 > agp0: on hostb0 > pcib1: at device 1.0 on pci0 > pci1: on pcib1 > vgapci0: mem > 0xde000000-0xdeffffff,0xc0000000-0xcfffffff irq 16 at device 0.0 on > pci1 > isab0: at device 2.0 on pci0 > isa0: on isab0 > atapci0: port > 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xff00-0xff0f at device 2.5 on > pci0 > ata0: on atapci0 > ata0: [ITHREAD] > ata1: on atapci0 > ata1: [ITHREAD] > ohci0: mem 0xdfffc000-0xdfffcfff irq 20 at > device 3.0 on pci0 > ohci0: [ITHREAD] > usbus0: on ohci0 > ohci1: mem 0xdfffd000-0xdfffdfff irq 21 at > device 3.1 on pci0 > ohci1: [ITHREAD] > usbus1: on ohci1 > ohci2: mem 0xdfffe000-0xdfffefff irq 22 at > device 3.2 on pci0 > ohci2: [ITHREAD] > usbus2: on ohci2 > ehci0: mem 0xdffff000-0xdfffffff > irq 23 at device 3.3 on pci0 > ehci0: [ITHREAD] > usbus3: EHCI version 1.0 > usbus3: on ehci0 > pcm0: port > 0xdc00-0xdc1f,0xd800-0xd80f,0xd400-0xd40f,0xd000-0xd03f irq 19 at > device 8.0 on pci0 > pcm0: [ITHREAD] > pcm0: system configuration > SubVendorID: 0x1412, SubDeviceID: 0xd63b > XIN2 Clock Source: 22.5792MHz(44.1kHz*512) > MPU-401 UART(s) #: 1 > AC'97 codec: not exist > ADC #: 4 > DAC #: 4 > Multi-track converter type: I2S(96KHz support, 24bit resolution, ID#0x2) > S/PDIF(IN/OUT): 1/1 ID# 0x00 > GPIO(mask/dir/state): 0x04/0xfb/0x7e > rl0: port 0xcc00-0xccff mem > 0xdfffbf00-0xdfffbfff irq 18 at device 11.0 on pci0 > miibus0: on rl0 > rlphy0: PHY 0 on miibus0 > rlphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto > rl0: Ethernet address: 00:10:dc:82:9b:d2 > rl0: [ITHREAD] > atrtc0: port 0x70-0x71 irq 8 on acpi0 > fdc1: port 0x3f2-0x3f3,0x3f4-0x3f5,0x3f7 irq > 6 drq 2 on acpi0 > fdc1: [FILTER] > uart0: <16550 or compatible> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 > uart0: [FILTER] > uart1: <16550 or compatible> port 0x2f8-0x2ff irq 3 on acpi0 > uart1: [FILTER] > ppc0: port 0x378-0x37f irq 7 on acpi0 > ppc0: Generic chipset (EPP/NIBBLE) in COMPATIBLE mode > ppc0: [ITHREAD] > ppbus0: on ppc0 > plip0: on ppbus0 > plip0: [ITHREAD] > lpt0: on ppbus0 > lpt0: [ITHREAD] > lpt0: Interrupt-driven port > ppi0: on ppbus0 > cpu0: on acpi0 > p4tcc0: on cpu0 > pmtimer0 on isa0 > orm0: at iomem 0xc0000-0xcffff,0xd0000-0xd27ff pnpid > ORM0000 on isa0 > sc0: at flags 0x100 on isa0 > sc0: VGA <16 virtual consoles, flags=0x300> > vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 > atkbdc0: at port 0x60,0x64 on isa0 > atkbd0: irq 1 on atkbdc0 > kbd0 at atkbd0 > atkbd0: [GIANT-LOCKED] > atkbd0: [ITHREAD] > fdc0: No FDOUT register! > Timecounter "TSC" frequency 2000150592 Hz quality 800 > Timecounters tick every 1.000 msec > usbus0: 12Mbps Full Speed USB v1.0 > usbus1: 12Mbps Full Speed USB v1.0 > usbus2: 12Mbps Full Speed USB v1.0 > usbus3: 480Mbps High Speed USB v2.0 > ad0: 57241MB at ata0-master UDMA100 > ugen0.1: at usbus0 > uhub0: on usbus0 > ugen1.1: at usbus1 > uhub1: on usbus1 > ugen2.1: at usbus2 > uhub2: on usbus2 > ugen3.1: at usbus3 > uhub3: on usbus3 > ad1: 57241MB at ata0-slave UDMA100 > uhub0: 2 ports with 2 removable, self powered > uhub1: 2 ports with 2 removable, self powered > uhub2: 2 ports with 2 removable, self powered > acd0: DVDROM at ata1-master UDMA33 > GEOM: ad0: partition 1 does not start on a track boundary. > GEOM: ad0: partition 1 does not end on a track boundary. > acd1: CDRW at ata1-slave UDMA33 > GEOM: ad0s2: geometry does not match label (255h,63s != 16h,255s). > GEOM: ad1: partition 1 does not start on a track boundary. > GEOM: ad1: partition 1 does not end on a track boundary. > uhub3: 6 ports with 6 removable, self powered > acd1: FAILURE - INQUIRY ILLEGAL REQUEST asc=0x24 ascq=0x00 > acd0: FAILURE - INQUIRY ILLEGAL REQUEST asc=0x24 ascq=0x00 > cd0 at ata1 bus 0 target 1 lun 0 > cd0: Removable CD-ROM SCSI-0 device > cd0: 33.000MB/s transfers > cd0: cd present [196100 x 2048 byte records] > cd1 at ata1 bus 0 target 0 lun 0 > cd1: Removable CD-ROM SCSI-0 device > cd1: 33.000MB/s transfers > cd1: cd present [3510947 x 2048 byte records] > GEOM_LABEL: Label for provider acd0 is iso9660/DIE_HARD_1. > GEOM_LABEL: Label for provider ad0s2a is ufsid/47fa91abbef03a13. > GEOM_LABEL: Label for provider ad0s2d is ufsid/47fa91ad7b28768a. > GEOM_LABEL: Label for provider ad0s2e is ufsid/47fa91abefc1e226. > GEOM_LABEL: Label for provider ad0s2f is ufsid/47fa91abfb5c1768. > GEOM: ad1s2: geometry does not match label (255h,63s != 16h,255s). > GEOM: ad1s3: geometry does not match label (16h,63s != 16h,255s). > ugen2.2: at usbus2 > ums0: on usbus2 > ums0: 3 buttons and [XYZ] coordinates ID=0 > GEOM_LABEL: Label for provider acd1 is iso9660/CDROM. > GEOM_LABEL: Label for provider ad1s2a is ufsid/423b25e8c0bf6015. > GEOM_LABEL: Label for provider ad1s2d is ufsid/423b25e933d9f5b1. > GEOM_LABEL: Label for provider ad1s2e is ufsid/423b25e88d1a575d. > GEOM_LABEL: Label for provider ad1s2f is ufsid/423b25e8f04b19a7. > GEOM_LABEL: Label for provider ad1s3g is ufsid/423de7c40ececa0b. > GEOM_LABEL: Label for provider ad1s3i is ufsid/423de7c57cc3c44b. > GEOM_LABEL: Label for provider ad1s3j is ufsid/423de7cf5ab394ca. > acd1: FAILURE - READ_BIG ILLEGAL REQUEST asc=0x64 ascq=0x00 > Trying to mount root from ufs:/dev/ad0s2a > GEOM_LABEL: Label ufsid/47fa91abbef03a13 removed. > GEOM_LABEL: Label for provider ad0s2a is ufsid/47fa91abbef03a13. > GEOM_LABEL: Label ufsid/47fa91abefc1e226 removed. > GEOM_LABEL: Label for provider ad0s2e is ufsid/47fa91abefc1e226. > GEOM_LABEL: Label ufsid/47fa91abfb5c1768 removed. > GEOM_LABEL: Label for provider ad0s2f is ufsid/47fa91abfb5c1768. > GEOM_LABEL: Label ufsid/47fa91ad7b28768a removed. > GEOM_LABEL: Label for provider ad0s2d is ufsid/47fa91ad7b28768a. > GEOM_LABEL: Label ufsid/47fa91abbef03a13 removed. > GEOM_LABEL: Label ufsid/47fa91abefc1e226 removed. > GEOM_LABEL: Label ufsid/47fa91abfb5c1768 removed. > GEOM_LABEL: Label ufsid/47fa91ad7b28768a removed. > rl0: link state changed to UP > >> vmstat -i > interrupt total rate > irq1: atkbd0 1823 1 > irq14: ata0 10943 7 > irq15: ata1 4692 3 > irq18: rl0 32566 22 > irq19: pcm0 99133 68 > irq22: ohci2 31197 21 > irq23: ehci0 2 0 > cpu0: timer 2872088 1998 > Total 3052444 2124 > >> cat /etc/rc.conf > > # -- sysinstall generated deltas -- # Mon Apr 7 23:50:43 2008 > # Created: Mon Apr 7 23:50:43 2008 > # Enable network daemons for user convenience. > # Please make all changes to this file, not to /etc/defaults/rc.conf. > # This file now contains just the overrides from /etc/defaults/rc.conf. > hostname="djdomics" > ifconfig_rl0="DHCP" > keymap="fr.iso.acc" > sshd_enable="YES" > gnome_enable="YES" > >> cat /etc/X11/xorg.conf > Section "ServerLayout" > Identifier "X.org Configured" > Screen 0 "Screen0" 0 0 > InputDevice "Mouse0" "CorePointer" > InputDevice "Keyboard0" "CoreKeyboard" > Option "AllowEmptyInput" "off" > EndSection > > Section "Files" > ModulePath "/usr/local/lib/xorg/modules" > FontPath "/usr/local/lib/X11/fonts/misc/" > FontPath "/usr/local/lib/X11/fonts/TTF/" > FontPath "/usr/local/lib/X11/fonts/OTF" > FontPath "/usr/local/lib/X11/fonts/Type1/" > FontPath "/usr/local/lib/X11/fonts/100dpi/" > FontPath "/usr/local/lib/X11/fonts/75dpi/" > EndSection > > Section "Module" > Load "dbe" > Load "dri" > Load "extmod" > Load "glx" > Load "record" > Load "xtrap" > Load "freetype" > EndSection > > Section "InputDevice" > Identifier "Keyboard0" > Driver "kbd" > Option "XkbLayout" "fr" > EndSection > > Section "InputDevice" > Identifier "Mouse0" > Driver "mouse" > Option "Protocol" "auto" > Option "Device" "/dev/sysmouse" > Option "ZAxisMapping" "4 5 6 7" > EndSection > > Section "Monitor" > #DisplaySize 320 240 # mm > Identifier "Monitor0" > VendorName "FUS" > ModelName "C700" > HorizSync 30.0 - 72.0 > VertRefresh 50.0 - 160.0 > Option "DPMS" > EndSection > > Section "Device" > ### Available Driver options are:- > ### Values: : integer, : float, : "True"/"False", > ### : "String", : " Hz/kHz/MHz" > ### [arg]: arg optional > #Option "SWcursor" # [] > #Option "HWcursor" # [] > #Option "NoAccel" # [] > #Option "ShadowFB" # [] > #Option "UseFBDev" # [] > #Option "Rotate" # [] > #Option "VideoKey" # > #Option "FlatPanel" # [] > #Option "FPDither" # [] > #Option "CrtcNumber" # > #Option "FPScale" # [] > #Option "FPTweak" # > #Option "DualHead" # [] > Identifier "Card0" > Driver "nv" > VendorName "nVidia Corporation" > BoardName "NV36 [GeForce FX 5700LE]" > BusID "PCI:1:0:0" > EndSection > > Section "Screen" > Identifier "Screen0" > Device "Card0" > Monitor "Monitor0" > SubSection "Display" > Viewport 0 0 > Depth 1 > EndSubSection > SubSection "Display" > Viewport 0 0 > Depth 4 > EndSubSection > SubSection "Display" > Viewport 0 0 > Depth 8 > EndSubSection > SubSection "Display" > Viewport 0 0 > Depth 15 > EndSubSection > SubSection "Display" > Viewport 0 0 > Depth 16 > EndSubSection > SubSection "Display" > Viewport 0 0 > Depth 24 > EndSubSection > EndSection > > > From dominique.goncalves at gmail.com Mon Apr 13 06:24:28 2009 From: dominique.goncalves at gmail.com (Dominique Goncalves) Date: Mon Apr 13 07:12:58 2009 Subject: Unusable Xorg with USB mouse In-Reply-To: <49E3362B.9040704@gwdg.de> References: <7daacbbe0904130203m62080028v14f6a1e4a3285dc0@mail.gmail.com> <49E3362B.9040704@gwdg.de> Message-ID: <7daacbbe0904130624r70509e06k1ceffecd7e902bb0@mail.gmail.com> Hi Rainer, On Mon, Apr 13, 2009 at 2:55 PM, Rainer Hurling wrote: > Hi Dominique, > > On 13.04.2009 11:03 (UTC+1), Dominique Goncalves wrote: >> >> Hi, >> >> I upgraded my FreeBSD desktop (XFCE4 and some applications) from >> 7.1-RELEASE to 8.0-CURRENT r190942 all ports was build from scratch >> after removing old files with make delete-old delete-old-libs. I should have been more precise, I followed these steps, upgrade to -CURRENT with the usual steps described in UPDATING (buildworld, buildkernel, installworld, installkernel, mergemaster, etc) # rm -fr /usr/local/* /var/db/pkg/* # cd /usr/src # yes | make delete-old # yes | make delete-old-libs and rebuild ports: xorg, xfce4, firefox3 > as far as I know 'make delete-old delete-old-libs' has to be done from > /usr/src and so it removes obsolete files from system (see > /usr/src/ObsoleteFiles.inc). > > To remove ports (/usr/ports) and build from scratch you have to 'pkg_delete > -a' or something like this... > >> Now it's very hard to listen music with mplayer, write text with vim, >> browse internet with firefox... it just stop working and restart when >> moving the mouse! > > There had been many changes in CURRENT and xorg in the last time. USB is > totally new, libusb is integrated in the system (please do not install that > port!) etc. > > So please read /usr/ports/UPDATING, especially the entries 20090309 and > 20090123. > > Hope I could help, > Rainer > > >> Let me know if you need more information. >> >> Any help is really appreciated, >> Thanks. >> >>> dmesg >> >> Copyright (c) 1992-2009 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 is a registered trademark of The FreeBSD Foundation. >> FreeBSD 8.0-CURRENT #0 r190942: Sat Apr 11 22:05:48 CEST 2009 >> ? ?root@djdomics:/usr/obj/usr/src/sys/GENERIC_NODEBUG >> Timecounter "i8254" frequency 1193182 Hz quality 0 >> CPU: Intel(R) Pentium(R) 4 CPU 2.00GHz (2000.15-MHz 686-class CPU) >> ?Origin = "GenuineIntel" ?Id = 0xf24 ?Stepping = 4 >> >> ?Features=0x3febfbff >> real memory ?= 805306368 (768 MB) >> avail memory = 774045696 (738 MB) >> ACPI APIC Table: >> MADT: Forcing active-low polarity and level trigger for SCI >> ioapic0 irqs 0-23 on motherboard >> kbd1 at kbdmux0 >> acpi0: on motherboard >> acpi0: [ITHREAD] >> acpi0: Power Button (fixed) >> Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 >> acpi_timer0: <24-bit timer at 3.579545MHz> port 0x808-0x80b on acpi0 >> acpi_button0: on acpi0 >> pcib0: port 0xcf8-0xcff on acpi0 >> pci0: on pcib0 >> agp0: on hostb0 >> pcib1: at device 1.0 on pci0 >> pci1: on pcib1 >> vgapci0: mem >> 0xde000000-0xdeffffff,0xc0000000-0xcfffffff irq 16 at device 0.0 on >> pci1 >> isab0: at device 2.0 on pci0 >> isa0: on isab0 >> atapci0: port >> 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xff00-0xff0f at device 2.5 on >> pci0 >> ata0: on atapci0 >> ata0: [ITHREAD] >> ata1: on atapci0 >> ata1: [ITHREAD] >> ohci0: mem 0xdfffc000-0xdfffcfff irq 20 at >> device 3.0 on pci0 >> ohci0: [ITHREAD] >> usbus0: on ohci0 >> ohci1: mem 0xdfffd000-0xdfffdfff irq 21 at >> device 3.1 on pci0 >> ohci1: [ITHREAD] >> usbus1: on ohci1 >> ohci2: mem 0xdfffe000-0xdfffefff irq 22 at >> device 3.2 on pci0 >> ohci2: [ITHREAD] >> usbus2: on ohci2 >> ehci0: mem 0xdffff000-0xdfffffff >> irq 23 at device 3.3 on pci0 >> ehci0: [ITHREAD] >> usbus3: EHCI version 1.0 >> usbus3: on ehci0 >> pcm0: port >> 0xdc00-0xdc1f,0xd800-0xd80f,0xd400-0xd40f,0xd000-0xd03f irq 19 at >> device 8.0 on pci0 >> pcm0: [ITHREAD] >> pcm0: system configuration >> ?SubVendorID: 0x1412, SubDeviceID: 0xd63b >> ?XIN2 Clock Source: 22.5792MHz(44.1kHz*512) >> ?MPU-401 UART(s) #: 1 >> ?AC'97 codec: not exist >> ?ADC #: 4 >> ?DAC #: 4 >> ?Multi-track converter type: I2S(96KHz support, 24bit resolution, ID#0x2) >> ?S/PDIF(IN/OUT): 1/1 ID# 0x00 >> ?GPIO(mask/dir/state): 0x04/0xfb/0x7e >> rl0: port 0xcc00-0xccff mem >> 0xdfffbf00-0xdfffbfff irq 18 at device 11.0 on pci0 >> miibus0: on rl0 >> rlphy0: PHY 0 on miibus0 >> rlphy0: ?10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto >> rl0: Ethernet address: 00:10:dc:82:9b:d2 >> rl0: [ITHREAD] >> atrtc0: port 0x70-0x71 irq 8 on acpi0 >> fdc1: port 0x3f2-0x3f3,0x3f4-0x3f5,0x3f7 irq >> 6 drq 2 on acpi0 >> fdc1: [FILTER] >> uart0: <16550 or compatible> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 >> uart0: [FILTER] >> uart1: <16550 or compatible> port 0x2f8-0x2ff irq 3 on acpi0 >> uart1: [FILTER] >> ppc0: port 0x378-0x37f irq 7 on acpi0 >> ppc0: Generic chipset (EPP/NIBBLE) in COMPATIBLE mode >> ppc0: [ITHREAD] >> ppbus0: on ppc0 >> plip0: on ppbus0 >> plip0: [ITHREAD] >> lpt0: on ppbus0 >> lpt0: [ITHREAD] >> lpt0: Interrupt-driven port >> ppi0: on ppbus0 >> cpu0: on acpi0 >> p4tcc0: on cpu0 >> pmtimer0 on isa0 >> orm0: at iomem 0xc0000-0xcffff,0xd0000-0xd27ff pnpid >> ORM0000 on isa0 >> sc0: at flags 0x100 on isa0 >> sc0: VGA <16 virtual consoles, flags=0x300> >> vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 >> atkbdc0: at port 0x60,0x64 on isa0 >> atkbd0: irq 1 on atkbdc0 >> kbd0 at atkbd0 >> atkbd0: [GIANT-LOCKED] >> atkbd0: [ITHREAD] >> fdc0: No FDOUT register! >> Timecounter "TSC" frequency 2000150592 Hz quality 800 >> Timecounters tick every 1.000 msec >> usbus0: 12Mbps Full Speed USB v1.0 >> usbus1: 12Mbps Full Speed USB v1.0 >> usbus2: 12Mbps Full Speed USB v1.0 >> usbus3: 480Mbps High Speed USB v2.0 >> ad0: 57241MB at ata0-master UDMA100 >> ugen0.1: at usbus0 >> uhub0: on usbus0 >> ugen1.1: at usbus1 >> uhub1: on usbus1 >> ugen2.1: at usbus2 >> uhub2: on usbus2 >> ugen3.1: at usbus3 >> uhub3: on usbus3 >> ad1: 57241MB at ata0-slave UDMA100 >> uhub0: 2 ports with 2 removable, self powered >> uhub1: 2 ports with 2 removable, self powered >> uhub2: 2 ports with 2 removable, self powered >> acd0: DVDROM at ata1-master UDMA33 >> GEOM: ad0: partition 1 does not start on a track boundary. >> GEOM: ad0: partition 1 does not end on a track boundary. >> acd1: CDRW at ata1-slave UDMA33 >> GEOM: ad0s2: geometry does not match label (255h,63s != 16h,255s). >> GEOM: ad1: partition 1 does not start on a track boundary. >> GEOM: ad1: partition 1 does not end on a track boundary. >> uhub3: 6 ports with 6 removable, self powered >> acd1: FAILURE - INQUIRY ILLEGAL REQUEST asc=0x24 ascq=0x00 >> acd0: FAILURE - INQUIRY ILLEGAL REQUEST asc=0x24 ascq=0x00 >> cd0 at ata1 bus 0 target 1 lun 0 >> cd0: Removable CD-ROM SCSI-0 device >> cd0: 33.000MB/s transfers >> cd0: cd present [196100 x 2048 byte records] >> cd1 at ata1 bus 0 target 0 lun 0 >> cd1: Removable CD-ROM SCSI-0 device >> cd1: 33.000MB/s transfers >> cd1: cd present [3510947 x 2048 byte records] >> GEOM_LABEL: Label for provider acd0 is iso9660/DIE_HARD_1. >> GEOM_LABEL: Label for provider ad0s2a is ufsid/47fa91abbef03a13. >> GEOM_LABEL: Label for provider ad0s2d is ufsid/47fa91ad7b28768a. >> GEOM_LABEL: Label for provider ad0s2e is ufsid/47fa91abefc1e226. >> GEOM_LABEL: Label for provider ad0s2f is ufsid/47fa91abfb5c1768. >> GEOM: ad1s2: geometry does not match label (255h,63s != 16h,255s). >> GEOM: ad1s3: geometry does not match label (16h,63s != 16h,255s). >> ugen2.2: at usbus2 >> ums0: on usbus2 >> ums0: 3 buttons and [XYZ] coordinates ID=0 >> GEOM_LABEL: Label for provider acd1 is iso9660/CDROM. >> GEOM_LABEL: Label for provider ad1s2a is ufsid/423b25e8c0bf6015. >> GEOM_LABEL: Label for provider ad1s2d is ufsid/423b25e933d9f5b1. >> GEOM_LABEL: Label for provider ad1s2e is ufsid/423b25e88d1a575d. >> GEOM_LABEL: Label for provider ad1s2f is ufsid/423b25e8f04b19a7. >> GEOM_LABEL: Label for provider ad1s3g is ufsid/423de7c40ececa0b. >> GEOM_LABEL: Label for provider ad1s3i is ufsid/423de7c57cc3c44b. >> GEOM_LABEL: Label for provider ad1s3j is ufsid/423de7cf5ab394ca. >> acd1: FAILURE - READ_BIG ILLEGAL REQUEST asc=0x64 ascq=0x00 >> Trying to mount root from ufs:/dev/ad0s2a >> GEOM_LABEL: Label ufsid/47fa91abbef03a13 removed. >> GEOM_LABEL: Label for provider ad0s2a is ufsid/47fa91abbef03a13. >> GEOM_LABEL: Label ufsid/47fa91abefc1e226 removed. >> GEOM_LABEL: Label for provider ad0s2e is ufsid/47fa91abefc1e226. >> GEOM_LABEL: Label ufsid/47fa91abfb5c1768 removed. >> GEOM_LABEL: Label for provider ad0s2f is ufsid/47fa91abfb5c1768. >> GEOM_LABEL: Label ufsid/47fa91ad7b28768a removed. >> GEOM_LABEL: Label for provider ad0s2d is ufsid/47fa91ad7b28768a. >> GEOM_LABEL: Label ufsid/47fa91abbef03a13 removed. >> GEOM_LABEL: Label ufsid/47fa91abefc1e226 removed. >> GEOM_LABEL: Label ufsid/47fa91abfb5c1768 removed. >> GEOM_LABEL: Label ufsid/47fa91ad7b28768a removed. >> rl0: link state changed to UP >> >>> vmstat -i >> >> interrupt ? ? ? ? ? ? ? ? ? ? ? ? ?total ? ? ? rate >> irq1: atkbd0 ? ? ? ? ? ? ? ? ? ? ? ?1823 ? ? ? ? ?1 >> irq14: ata0 ? ? ? ? ? ? ? ? ? ? ? ?10943 ? ? ? ? ?7 >> irq15: ata1 ? ? ? ? ? ? ? ? ? ? ? ? 4692 ? ? ? ? ?3 >> irq18: rl0 ? ? ? ? ? ? ? ? ? ? ? ? 32566 ? ? ? ? 22 >> irq19: pcm0 ? ? ? ? ? ? ? ? ? ? ? ?99133 ? ? ? ? 68 >> irq22: ohci2 ? ? ? ? ? ? ? ? ? ? ? 31197 ? ? ? ? 21 >> irq23: ehci0 ? ? ? ? ? ? ? ? ? ? ? ? ? 2 ? ? ? ? ?0 >> cpu0: timer ? ? ? ? ? ? ? ? ? ? ?2872088 ? ? ? 1998 >> Total ? ? ? ? ? ? ? ? ? ? ? ? ? ?3052444 ? ? ? 2124 >> >>> cat /etc/rc.conf >> >> # -- sysinstall generated deltas -- # Mon Apr ?7 23:50:43 2008 >> # Created: Mon Apr ?7 23:50:43 2008 >> # Enable network daemons for user convenience. >> # Please make all changes to this file, not to /etc/defaults/rc.conf. >> # This file now contains just the overrides from /etc/defaults/rc.conf. >> hostname="djdomics" >> ifconfig_rl0="DHCP" >> keymap="fr.iso.acc" >> sshd_enable="YES" >> gnome_enable="YES" >> >>> cat /etc/X11/xorg.conf >> >> Section "ServerLayout" >> ? ? ? ?Identifier ? ? "X.org Configured" >> ? ? ? ?Screen ? ? ?0 ?"Screen0" 0 0 >> ? ? ? ?InputDevice ? ?"Mouse0" "CorePointer" >> ? ? ? ?InputDevice ? ?"Keyboard0" "CoreKeyboard" >> ? ? ? ?Option ? ? ? ? "AllowEmptyInput" "off" >> EndSection >> >> Section "Files" >> ? ? ? ?ModulePath ? "/usr/local/lib/xorg/modules" >> ? ? ? ?FontPath ? ? "/usr/local/lib/X11/fonts/misc/" >> ? ? ? ?FontPath ? ? "/usr/local/lib/X11/fonts/TTF/" >> ? ? ? ?FontPath ? ? "/usr/local/lib/X11/fonts/OTF" >> ? ? ? ?FontPath ? ? "/usr/local/lib/X11/fonts/Type1/" >> ? ? ? ?FontPath ? ? "/usr/local/lib/X11/fonts/100dpi/" >> ? ? ? ?FontPath ? ? "/usr/local/lib/X11/fonts/75dpi/" >> EndSection >> >> Section "Module" >> ? ? ? ?Load ?"dbe" >> ? ? ? ?Load ?"dri" >> ? ? ? ?Load ?"extmod" >> ? ? ? ?Load ?"glx" >> ? ? ? ?Load ?"record" >> ? ? ? ?Load ?"xtrap" >> ? ? ? ?Load ?"freetype" >> EndSection >> >> Section "InputDevice" >> ? ? ? ?Identifier ?"Keyboard0" >> ? ? ? ?Driver ? ? ?"kbd" >> ? ? ? ?Option ? ? ?"XkbLayout" "fr" >> EndSection >> >> Section "InputDevice" >> ? ? ? ?Identifier ?"Mouse0" >> ? ? ? ?Driver ? ? ?"mouse" >> ? ? ? ?Option ? ? ?"Protocol" "auto" >> ? ? ? ?Option ? ? ?"Device" "/dev/sysmouse" >> ? ? ? ?Option ? ? ?"ZAxisMapping" "4 5 6 7" >> EndSection >> >> Section "Monitor" >> ? ? ? ?#DisplaySize ? ? ?320 ? 240 ? ? # mm >> ? ? ? ?Identifier ? "Monitor0" >> ? ? ? ?VendorName ? "FUS" >> ? ? ? ?ModelName ? ?"C700" >> ? ? ? ?HorizSync ? ?30.0 - 72.0 >> ? ? ? ?VertRefresh ?50.0 - 160.0 >> ? ? ? ?Option ? ? ?"DPMS" >> EndSection >> >> Section "Device" >> ? ? ? ?### Available Driver options are:- >> ? ? ? ?### Values: : integer, : float, : "True"/"False", >> ? ? ? ?### : "String", : " Hz/kHz/MHz" >> ? ? ? ?### [arg]: arg optional >> ? ? ? ?#Option ? ? "SWcursor" ? ? ? ? ? ? ? ? ?# [] >> ? ? ? ?#Option ? ? "HWcursor" ? ? ? ? ? ? ? ? ?# [] >> ? ? ? ?#Option ? ? "NoAccel" ? ? ? ? ? ? ? ? ? # [] >> ? ? ? ?#Option ? ? "ShadowFB" ? ? ? ? ? ? ? ? ?# [] >> ? ? ? ?#Option ? ? "UseFBDev" ? ? ? ? ? ? ? ? ?# [] >> ? ? ? ?#Option ? ? "Rotate" ? ? ? ? ? ? ? ? ? ?# [] >> ? ? ? ?#Option ? ? "VideoKey" ? ? ? ? ? ? ? ? ?# >> ? ? ? ?#Option ? ? "FlatPanel" ? ? ? ? ? ? ? ? # [] >> ? ? ? ?#Option ? ? "FPDither" ? ? ? ? ? ? ? ? ?# [] >> ? ? ? ?#Option ? ? "CrtcNumber" ? ? ? ? ? ? ? ?# >> ? ? ? ?#Option ? ? "FPScale" ? ? ? ? ? ? ? ? ? # [] >> ? ? ? ?#Option ? ? "FPTweak" ? ? ? ? ? ? ? ? ? # >> ? ? ? ?#Option ? ? "DualHead" ? ? ? ? ? ? ? ? ?# [] >> ? ? ? ?Identifier ?"Card0" >> ? ? ? ?Driver ? ? ?"nv" >> ? ? ? ?VendorName ?"nVidia Corporation" >> ? ? ? ?BoardName ? "NV36 [GeForce FX 5700LE]" >> ? ? ? ?BusID ? ? ? "PCI:1:0:0" >> EndSection >> >> Section "Screen" >> ? ? ? ?Identifier "Screen0" >> ? ? ? ?Device ? ? "Card0" >> ? ? ? ?Monitor ? ?"Monitor0" >> ? ? ? ?SubSection "Display" >> ? ? ? ? ? ? ? ?Viewport ? 0 0 >> ? ? ? ? ? ? ? ?Depth ? ? 1 >> ? ? ? ?EndSubSection >> ? ? ? ?SubSection "Display" >> ? ? ? ? ? ? ? ?Viewport ? 0 0 >> ? ? ? ? ? ? ? ?Depth ? ? 4 >> ? ? ? ?EndSubSection >> ? ? ? ?SubSection "Display" >> ? ? ? ? ? ? ? ?Viewport ? 0 0 >> ? ? ? ? ? ? ? ?Depth ? ? 8 >> ? ? ? ?EndSubSection >> ? ? ? ?SubSection "Display" >> ? ? ? ? ? ? ? ?Viewport ? 0 0 >> ? ? ? ? ? ? ? ?Depth ? ? 15 >> ? ? ? ?EndSubSection >> ? ? ? ?SubSection "Display" >> ? ? ? ? ? ? ? ?Viewport ? 0 0 >> ? ? ? ? ? ? ? ?Depth ? ? 16 >> ? ? ? ?EndSubSection >> ? ? ? ?SubSection "Display" >> ? ? ? ? ? ? ? ?Viewport ? 0 0 >> ? ? ? ? ? ? ? ?Depth ? ? 24 >> ? ? ? ?EndSubSection >> EndSection >> >> >> > -- There's this old saying: "Give a man a fish, feed him for a day. Teach a man to fish, feed him for life." From rmacklem at uoguelph.ca Mon Apr 13 06:49:01 2009 From: rmacklem at uoguelph.ca (Rick Macklem) Date: Mon Apr 13 07:16:22 2009 Subject: [HEADSUP] nfsserver module now depends on nfssvc module Message-ID: Oops, sorry. I should have sent this out before the commit... The nfsserver modules now depends on another module called nfssvc. You'll need to do a fresh "config ", followed by a build sequence. If you don't "make KERNEL= install" and run the nfsd for a config that doesn't have "options NFSSERVER", you'll need to build/copy both the nfsserver and nfssvc modules. rick From rmacklem at uoguelph.ca Mon Apr 13 06:53:11 2009 From: rmacklem at uoguelph.ca (Rick Macklem) Date: Mon Apr 13 07:19:13 2009 Subject: NFS errors on compile of -current In-Reply-To: <1239599205.24831.3.camel@localhost.localdomain> References: <1239599205.24831.3.camel@localhost.localdomain> Message-ID: On Sun, 12 Apr 2009, Sean Bruno wrote: > [sean@bsd64 ~/bsd/head/sys/amd64/compile/SBP_TARG]$ make > linking kernel.debug > nfs_srvsubs.o(.text+0xd0c): In function `nfsrv_modevent': > ../../../nfsserver/nfs_srvsubs.c:560: undefined reference to > `nfsd_call_nfsserver' > nfs_srvsubs.o(.text+0xd42):../../../nfsserver/nfs_srvsubs.c:569: > undefined reference to `nfsd_call_nfsserver' > *** Error code 1 > > Stop in /usr/home/sean/bsd/head/sys/amd64/compile/SBP_TARG. > Yes, sorry. I just sent a HEADSUP, but should have done it before doing the commit. You need to do a fresh "config " and kernel build sequence, so that nfs_nfssvc.c gets built. rick From sean.bruno at dsl-only.net Mon Apr 13 08:27:45 2009 From: sean.bruno at dsl-only.net (Sean Bruno) Date: Mon Apr 13 08:48:04 2009 Subject: NFS errors on compile of -current In-Reply-To: References: <1239599205.24831.3.camel@localhost.localdomain> Message-ID: <1239636463.24831.34.camel@localhost.localdomain> On Mon, 2009-04-13 at 09:59 -0400, Rick Macklem wrote: > > On Sun, 12 Apr 2009, Sean Bruno wrote: > > > [sean@bsd64 ~/bsd/head/sys/amd64/compile/SBP_TARG]$ make > > linking kernel.debug > > nfs_srvsubs.o(.text+0xd0c): In function `nfsrv_modevent': > > ../../../nfsserver/nfs_srvsubs.c:560: undefined reference to > > `nfsd_call_nfsserver' > > nfs_srvsubs.o(.text+0xd42):../../../nfsserver/nfs_srvsubs.c:569: > > undefined reference to `nfsd_call_nfsserver' > > *** Error code 1 > > > > Stop in /usr/home/sean/bsd/head/sys/amd64/compile/SBP_TARG. > > > Yes, sorry. I just sent a HEADSUP, but should have done it before doing > the commit. You need to do a fresh "config " and kernel build > sequence, so that nfs_nfssvc.c gets built. > > rick > Yup. Thanks! Sean From eculp at encontacto.net Mon Apr 13 08:34:07 2009 From: eculp at encontacto.net (eculp) Date: Mon Apr 13 09:06:19 2009 Subject: Flash10, with up to date current, not even recoginized with about:plugins. Message-ID: <20090413054500.1241102uwgs74khc@econet.encontacto.net> I'm using up to date current # uname -a FreeBSD ed.local.net.mx 8.0-CURRENT FreeBSD 8.0-CURRENT #203: Sun Apr 12 15:13:50 CDT 2009 A copy of my about:plugins is at: http://www.encontacto.net/SHARE/About_Plugins.html I have installed all the f8 ports, I think. linux-f8-alsa-lib-1.0.15 linux-f8-aspell-0.60.5 linux-f8-atk-1.20.0 linux-f8-cairo-1.4.14 linux-f8-curl-7.18.2 linux-f8-expat-2.0.1 linux-f8-fontconfig-2.4.2 linux-f8-gtk2-2.12.8 linux-f8-hicolor-icon-theme-0.5 linux-f8-jpeg-6b linux-f8-libidn-0.6.14 linux-f8-libsigc++20-2.0.18 linux-f8-libssh2-0.18 linux-f8-nspr-4.7.3 linux-f8-nss-3.12.2.0 linux-f8-openssl-0.9.8b linux-f8-pango-1.18.4 linux-f8-png-1.2.22 linux-f8-scim-libs-1.4.7 linux-f8-sqlite3-3.4.2 linux-f8-tiff-3.8.2 linux-f8-xorg-libs-7.3_2 linux_base-f8-8_11 linux-flashplugin-10.0r22 nspluginwrapper-1.2.2_2 # nspluginwrapper -v -a -i Auto-install plugins from /usr/local/lib/browser_plugins Looking for plugins in /usr/local/lib/browser_plugins Auto-install plugins from /usr/local/lib/firefox/plugins Looking for plugins in /usr/local/lib/firefox/plugins Auto-install plugins from /usr/local/lib/linux-mozilla/plugins Looking for plugins in /usr/local/lib/linux-mozilla/plugins Install plugin /usr/local/lib/linux-mozilla/plugins/nphelix.so into /usr/local/lib/browser_plugins/npwrapper.nphelix.so Install plugin /usr/local/lib/linux-mozilla/plugins/mplayerplug-in-dvx.so into /usr/local/lib/browser_plugins/npwrapper.mplayerplug-in-dvx.so Install plugin /usr/local/lib/linux-mozilla/plugins/mplayerplug-in-qt.so into /usr/local/lib/browser_plugins/npwrapper.mplayerplug-in-qt.so Install plugin /usr/local/lib/linux-mozilla/plugins/mplayerplug-in-rm.so into /usr/local/lib/browser_plugins/npwrapper.mplayerplug-in-rm.so Install plugin /usr/local/lib/linux-mozilla/plugins/mplayerplug-in-wmp.so into /usr/local/lib/browser_plugins/npwrapper.mplayerplug-in-wmp.so Install plugin /usr/local/lib/linux-mozilla/plugins/mplayerplug-in.so into /usr/local/lib/browser_plugins/npwrapper.mplayerplug-in.so Install plugin /usr/local/lib/linux-mozilla/plugins/libflashplayer.so into /usr/local/lib/browser_plugins/npwrapper.libflashplayer.so Auto-install plugins from /usr/local/lib/npapi/linux-flashplugin Looking for plugins in /usr/local/lib/npapi/linux-flashplugin Install plugin /usr/local/lib/npapi/linux-flashplugin/libflashplayer.so into /usr/local/lib/browser_plugins/npwrapper.libflashplayer.so Auto-install plugins from /root/.mozilla/plugins Looking for plugins in /root/.mozilla/plugins Install plugin /root/.mozilla/plugins/nppdf.so into /root/.mozilla/plugins/npwrapper.nppdf.so From that I would assume that it is working but it isn't and I'm stymied. Over the years I've used flash 7 and later 9 with no major problems. Any suggestions on what I might have missed would be appreciated. ed PS I did notice a userid (0) unknown with a couple of the linux-f8 portw while installing them with portmaster and they installed fine. IIRC gtk2 was one and scim was the other. From CQG00620 at nifty.ne.jp Mon Apr 13 08:56:33 2009 From: CQG00620 at nifty.ne.jp (WATANABE Kazuhiro) Date: Mon Apr 13 09:49:50 2009 Subject: New ioctl to support Enhanced CD (or Extra CD) In-Reply-To: <49DDF942.9040808@FreeBSD.org> References: <49DDF942.9040808@FreeBSD.org> Message-ID: <20090413153547.6788170220@mail1.asahi-net.or.jp> Hi. I've tested your patch, and found some problems. (1) Cannot mount a data part. capricorn# cdcontrol info Starting track = 1, ending track = 12, TOC size = 106 bytes track start duration block length type ------------------------------------------------- 1 0:02.00 6:18.00 0 28350 audio 2 6:20.00 6:03.10 28350 27235 audio 3 12:23.10 5:32.37 55585 24937 audio 4 17:55.47 3:35.65 80522 16190 audio 5 21:31.37 5:28.33 96712 24633 audio 6 26:59.70 3:58.15 121345 17865 audio 7 30:58.10 4:57.62 139210 22337 audio 8 35:55.72 4:58.55 161547 22405 audio 9 40:54.52 6:28.68 183952 29168 audio 10 47:23.45 5:01.50 213120 22625 audio 11 52:25.20 6:48.32 235745 30632 audio 12 61:45.52 8:10.74 277777 36824 data 170 69:56.51 - 314601 - - capricorn# mount_cd9660 /dev/acd0 /cdrom mount_cd9660: /dev/acd0: Invalid argument capricorn# (2) When I read the last audio track via /dev/acd0tXX, the output data has wrong length. capricorn# dd if=/dev/acd0t10 bs=2352 > /dev/null 22625+0 records in 22625+0 records out # correct length 53214000 bytes transferred in 19.750258 secs (2694345 bytes/sec) capricorn# dd if=/dev/acd0t11 bs=2352 > /dev/null dd: /dev/acd0t11: Input/output error 41883+0 records in 41883+0 records out # wrong length (!= 30632) 98508816 bytes transferred in 35.804241 secs (2751317 bytes/sec) capricorn# (3) When I play the last audio track with cdcontrol(1), the "next" command doesn't work (the drive stops playing). capricorn# cdcontrol play 11 capricorn# cdcontrol status Audio status = 17, current track = 11, current position = 0:13.68 No media catalog info available Left volume = 255, right volume = 255 capricorn# cdcontrol next acd0: FAILURE - PLAY_MSF ILLEGAL REQUEST asc=0x64 ascq=0x00 capricorn# cdcontrol status Audio status = 0, current track = 11, current position = 0:26.57 Media catalog is inactive Left volume = 255, right volume = 255 capricorn# (These tests are done with Noriyuki Makihara's "Such a Lovely Place" (Sony Records, 1997).) By the way, I have an another patch that solves problems that you have pointed out and described above. http://homepage2.nifty.com/dumb_show/unix/work/ata.releng71.diff http://homepage2.nifty.com/dumb_show/unix/work/cdcontrol.releng71.diff I've tested the patch on FreeBSD 7.1-RELEASE and 8-current. This patch is not my original. The original patch was written by Chiharu Shibata for FreeBSD 4.4-RELEASE. http://www32.ocn.ne.jp/~chi/myprog/FreeBSD/atapi-cd.html One year later he rewrote the patch for FreeBSD 4.7-RELEASE. It also includes some quirks for old CD-ROM drives which are generally used with NEC PC-98 series. http://home.jp.freebsd.org/cgi-bin/showmail/FreeBSD-users-jp/74432 I rewrote the latter patch for FreeBSD 5.x, 6.x, and 7.x. At Thu, 09 Apr 2009 15:33:54 +0200, Jean-S?bastien P?dron wrote: > Hello, > > Enhanced CD (or Extra CA) is an Audio CD with an additionnal data track > at the end. Audio tracks belong to the first session while the data > track belongs to the second session. Therefore the last audio track ends > way before the data track start. > > The first consequence is that the duration of the last audio track isn't > reported correctly. Here is the output of cdcontrol(1) with such a CD[1]: > $ cdcontrol info > ... > 12 46:03.67 9:54.43 207142 44593 audio > 13 55:58.35 6:38.51 251735 29901 data > > The expected output is: > $ cdcontrol info > ... > 12 46:03.67 7:22.43 207142 33193 audio > 13 55:58.35 6:38.51 251735 29901 data > > A more "audible" consequence is that cdparanoia(1) copies 9'54" of data > instead of 7'22". The end of the ripped file is full of garbage. > > I made a patch (attached) that adds a new ioctl to query the start > address of the last session. This new ioctl is named > CDIOREADLASTSESSIONADDR. The patch also includes changes to cdcontrol(1). > > I added a new member at the end of struct acd_softc to store the last > session address. I don't know if this causes ABI breakage. > > Linux' corresponding ioctl is CDROMMULTISESSION. Beside this address, it > returns a flag named "xa_flag". Currently, I don't understand what it is > but it may be useful to add it to our ioctl too if someone knows its > purpose. > > Before I spend some time to teach cdparanoia(1) about this new ioctl, > I'd like some feedback on this patch, especially the name and the struct > ioc_read_last_session_addr. I would appreciate some test reports too! :) > > [1] This was tested with Avishai Cohen's last album, "Aurora". > > -- > Jean-S?bastien P?dron > http://www.dumbbell.fr/ (snip) --- WATANABE Kazuhiro (CQG00620@nifty.ne.jp) From jhb at freebsd.org Mon Apr 13 10:55:11 2009 From: jhb at freebsd.org (John Baldwin) Date: Mon Apr 13 11:16:56 2009 Subject: AMD 780G chipset major issues 3/3 (btx) In-Reply-To: <83e5fb980904081237u4e2979b9tad38d62a061d85b8@mail.gmail.com> References: <83e5fb980904061402q73940f8at4ec4b8f821354320@mail.gmail.com> <200904071026.26735.jhb@freebsd.org> <83e5fb980904081237u4e2979b9tad38d62a061d85b8@mail.gmail.com> Message-ID: <200904131305.12605.jhb@freebsd.org> On Wednesday 08 April 2009 3:37:38 pm Diego Depaoli wrote: > On Tue, Apr 7, 2009 at 4:26 PM, John Baldwin wrote: > > On Monday 06 April 2009 5:02:53 pm Diego Depaoli wrote: > >> And finally... > >> if I enable ahci in bios the system won't boot ?with btx halted. > >> Ctrl+alt+del is the only allowed action. > >> > >> Yes... it's a low cost motherboard, but I'm a bit confused. > > > > What OS release are you running? > > 8.0-CURRENT FreeBSD 8.0-CURRENT #19: Sun Apr 5 02:25:34 CEST 2009 > FreeBSD version 800074 Very odd, can you get a copy of the BTX fault output? -- John Baldwin From jhb at freebsd.org Mon Apr 13 10:55:14 2009 From: jhb at freebsd.org (John Baldwin) Date: Mon Apr 13 11:17:06 2009 Subject: ZFS checksum errors on USB attach (Was: ZFS data error without reasons) In-Reply-To: <20090409003108.fe768d54.nork@FreeBSD.org> References: <49BD117B.2080706@163.com> <012d01c9b706$ccace720$6606b560$@Sparrevohn@btinternet.com> <20090409003108.fe768d54.nork@FreeBSD.org> Message-ID: <200904131304.43585.jhb@freebsd.org> On Wednesday 08 April 2009 11:31:08 am Norikatsu Shigemura wrote: > Hi jhb! > > I got ZFS checksum error issue, too. So I found a way of fixing > this issue. Please back out following change. > > sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_dir.c > - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - > revision 1.5 > date: 2009/03/18 16:19:44; author: jhb; state: Exp; lines: +2 -0 > SVN rev 189967 on 2009-03-18 16:19:44Z by jhb > > The zfs_get_xattrdir() function is used to find the extended attribute > directory for a znode. When the directory already exists, it returns a > referenced but unlocked vnode. When a directory does not yet exist, it > calls zfs_make_xattrdir() to create a new one. zfs_make_xattrdir() returns > the vnode both referenced and and locked and zfs_get_xattrdir() was leaking > this vnode lock to its callers. Fix this by dropping the vnode lock if > zfs_make_xattrdir() successfully creates a new extended attribute > directory. > > Reviewed by: pjd > - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - > > [Validation] > 1. I got ZFS checksum error issue > 2. Backup > 3. Restructure ZPool > 4. Restore (But ZFS checksum error) > 5. Restructure ZPool with kern.smp.disabled=1 > (Almost good, but...) > 6. Restore > 7. Backout zfs_dir#1.5 > 8. Good works for me > > I tested many backup&restore:-). I have no idea how this would break what you are seeing. The zfs_get_xattrdir() function is only called from zfs_lookup() when LOOKUP_XATTR is specified, and that only happens from the extended attribute VOP routines. Are you using extended attributes at all? Also, have you tried running with INVARIANTS and DEBUG_VFS_LOCKS to catch missing locks? -- John Baldwin From alc at cs.rice.edu Mon Apr 13 11:01:34 2009 From: alc at cs.rice.edu (Alan Cox) Date: Mon Apr 13 11:18:47 2009 Subject: [Fwd: svn commit: r190949 - head/sys/vm] In-Reply-To: <7d6fde3d0904121506u5ed82765oe6fd73231f4c6b97@mail.gmail.com> References: <49E11CE7.5050903@cs.rice.edu> <49E172A3.2000108@samsco.org> <49E174DE.90603@cs.rice.edu> <7d6fde3d0904121506u5ed82765oe6fd73231f4c6b97@mail.gmail.com> Message-ID: <49E37DF4.5010301@cs.rice.edu> Garrett Cooper wrote: > On Sat, Apr 11, 2009 at 9:58 PM, Alan Cox wrote: > >> Scott Long wrote: >> >>> Off the top of my head, I would almost expect this to conflict with >>> Java. Haven't tried it, though, so I can't do anything more than >>> speculate. However, I would encourage testing here. >>> >>> >> It doesn't. I verified that the Sun JVM works. >> > > Has this been verified with Perl / Python yet? > -Garrett > Python, yes. In general, I wouldn't worry about any language implementation that doesn't include a JIT compiler. Alan From jhb at freebsd.org Mon Apr 13 11:50:57 2009 From: jhb at freebsd.org (John Baldwin) Date: Mon Apr 13 12:31:45 2009 Subject: can't boot 5.5 TB GPT disk In-Reply-To: <49E1819B.7000604@jrv.org> References: <49E1819B.7000604@jrv.org> Message-ID: <200904131432.55697.jhb@freebsd.org> On Sunday 12 April 2009 1:52:27 am James R. Van Artsdalen wrote: > FreeBSD bigback.housenet.jrv 8.0-CURRENT FreeBSD 8.0-CURRENT #0 r190917: > Sat Apr 11 19:48:25 CDT 2009 > james@bigback.housenet.jrv:/usr/obj/usr/src/sys/GENERIC amd64 > > I can't boot a GPT partitioned 5.5 TB disc, where the UFS root partition > is near the end of the disk. If I put another disk in the system and > mount root from the GPT disk the system runs fine. > > The 5.5 TB disk is partitioned: > > bigback# gpart show > => 34 11718748093 ad6 GPT (5.5T) > 34 6 - free - (3.0K) > 40 409600 1 efi (200M) > 409640 11634190128 2 !6a898cc3-1dd2-11b2-99a6-080020736631 > (5.4T) > 11634599768 128 3 freebsd-boot (64K) > 11634599896 4194304 4 freebsd-ufs (2.0G) > 11638794200 33554432 5 freebsd-swap (16G) > 11672348632 4194304 6 freebsd-ufs (2.0G) > 11676542936 33554432 7 freebsd-ufs (16G) > 11710097368 8388608 8 freebsd-ufs (4.0G) > 11718485976 262151 - free - (128M) > > If I try to boot it (disk1 so pressing F5 here) it fails looking like > this (there is no UART available so this is typed from a pic, with typos): > > F1 FreeBSD > F5 Drive 1 > > Default: F1 > > BTX Loader 1.00 BTX version is 1.02 > Consoles: internal video/keyboard > BIOS drive C: is disk0 > BIOS drive D: is disk1 > BIOS 630kb/3136864kB available memory > > FreeBSD/i386 bootstrap loader, Revision 1.1 > (james@bigback.housenet.jrv, Sat Apr 11 08:19:00 CDT 2009 > \ > can't load 'kernel' > > Type '?' for a list of commands, 'help' for more details > OK > > To get this far suggests to me that PMBR and GPTBOOT worked, and that > the problem is elsewhere. Suggestions? Could there be a 32-bit > truncation lurking in a loader somewhere? > > PS. Note that the "lsdev' command causes the loader to crash while > printing out the info on the big disk, right after the EFI line for ad6p1... I would first try to fix the lsdev crash. You can use forever loops and printfs to narrow down the cause of the crash if needed. The biosdisk.c code should be able to handle 64-bit LBAs. -- John Baldwin From roberthuff at rcn.com Mon Apr 13 12:00:43 2009 From: roberthuff at rcn.com (Robert Huff) Date: Mon Apr 13 12:33:40 2009 Subject: changes to kernel config file Message-ID: <18915.35172.938891.672609@jerusalem.litteratus.org> I'm about to update a -CURRENT box, and came across this in src/UPDATING: GEOM_PART has become the default partition slicer for storage devices, replacing GEOM_MBR, GEOM_BSD, GEOM_PC98 and GEOM_GPT slicers. It introduces some changes: 1) In order for the new system to work, what - if anything - do I need to put in the config file? 2) will adding "options GEOM_PART_GPT" cause problems? With respect to the changes in the USB stack: The old system was built in early February, before the new code went in. The config file has: device uhci device ohci device ehci device usb device ukbd device ums Do I need to change anything? (Pointers for explanations are good.) Do I need ugen? Uhid? Respectfully, Robert Huff From rodrigc at crodrigues.org Mon Apr 13 12:33:11 2009 From: rodrigc at crodrigues.org (Craig Rodrigues) Date: Mon Apr 13 13:05:49 2009 Subject: [HEADSUP] nfsserver module now depends on nfssvc module In-Reply-To: References: Message-ID: <20090413193306.GA31219@crodrigues.org> On Mon, Apr 13, 2009 at 09:55:25AM -0400, Rick Macklem wrote: > Oops, sorry. I should have sent this out before the commit... Why didn't you put this information in /usr/src/UPDATING? -- Craig Rodrigues rodrigc@crodrigues.org From rmacklem at uoguelph.ca Mon Apr 13 14:33:03 2009 From: rmacklem at uoguelph.ca (Rick Macklem) Date: Mon Apr 13 14:54:37 2009 Subject: [HEADSUP] nfsserver module now depends on nfssvc module In-Reply-To: <20090413193306.GA31219@crodrigues.org> References: <20090413193306.GA31219@crodrigues.org> Message-ID: On Mon, 13 Apr 2009, Craig Rodrigues wrote: > On Mon, Apr 13, 2009 at 09:55:25AM -0400, Rick Macklem wrote: >> Oops, sorry. I should have sent this out before the commit... > > Why didn't you put this information in /usr/src/UPDATING? > Because I'm a newbie at this commiting stuff and didn't know, rick (I'll go look and see what UPDATING is.) From jkim at FreeBSD.org Mon Apr 13 15:37:11 2009 From: jkim at FreeBSD.org (Jung-uk Kim) Date: Mon Apr 13 15:48:43 2009 Subject: AMD 780G chipset major issues 3/3 (btx) In-Reply-To: <200904131305.12605.jhb@freebsd.org> References: <83e5fb980904061402q73940f8at4ec4b8f821354320@mail.gmail.com> <83e5fb980904081237u4e2979b9tad38d62a061d85b8@mail.gmail.com> <200904131305.12605.jhb@freebsd.org> Message-ID: <200904131836.57686.jkim@FreeBSD.org> On Monday 13 April 2009 01:05 pm, John Baldwin wrote: > On Wednesday 08 April 2009 3:37:38 pm Diego Depaoli wrote: > > On Tue, Apr 7, 2009 at 4:26 PM, John Baldwin wrote: > > > On Monday 06 April 2009 5:02:53 pm Diego Depaoli wrote: > > >> And finally... > > >> if I enable ahci in bios the system won't boot  with btx > > >> halted. Ctrl+alt+del is the only allowed action. > > >> > > >> Yes... it's a low cost motherboard, but I'm a bit confused. > > > > > > What OS release are you running? > > > > 8.0-CURRENT FreeBSD 8.0-CURRENT #19: Sun Apr 5 02:25:34 CEST > > 2009 FreeBSD version 800074 > > Very odd, can you get a copy of the BTX fault output? As I said earlier, I have a similar board and this is what I got: int=0000000d err=00000000 efl=00030002 eip=000001b1 eax=00000011 ebx=00000002 ecx=00009d82 edx=0009dbc8 esi=000003f0 edi=00000368 ebp=000003a8 esp=00000362 cs=cf00 ds=0040 es=1400 fs=0000 gs=0000 ss=9d82 cs:eip=2e 0f 01 16 7d 00 0f 20-c0 0c 01 0f 22 c0 eb 00 b8 08 00 8e d8 8e c0 8e-d0 66 2e a1 54 00 66 8b ss:esp=3f 00 c0 96 00 00 11 00-00 00 00 14 40 00 02 2f 46 00 02 00 00 00 f0 03-00 00 a8 03 00 00 94 03 The following is the disassembled code: 0: 2e 0f 01 16 lgdtl %cs:(%esi) 4: 7d 00 jge 0x6 6: 0f 20 c0 mov %cr0,%eax 9: 0c 01 or $0x1,%al b: 0f 22 c0 mov %eax,%cr0 e: eb 00 jmp 0x10 10: b8 08 00 8e d8 mov $0xd88e0008,%eax 15: 8e c0 mov %eax,%es 17: 8e d0 mov %eax,%ss 19: 66 2e a1 54 00 66 8b mov %cs:0x8b660054,%ax Jung-uk Kim From jkim at FreeBSD.org Mon Apr 13 16:16:54 2009 From: jkim at FreeBSD.org (Jung-uk Kim) Date: Mon Apr 13 16:35:28 2009 Subject: AMD 780G chipset major issues 3/3 (btx) In-Reply-To: <200904131836.57686.jkim@FreeBSD.org> References: <83e5fb980904061402q73940f8at4ec4b8f821354320@mail.gmail.com> <200904131305.12605.jhb@freebsd.org> <200904131836.57686.jkim@FreeBSD.org> Message-ID: <200904131916.41157.jkim@FreeBSD.org> On Monday 13 April 2009 06:36 pm, Jung-uk Kim wrote: > On Monday 13 April 2009 01:05 pm, John Baldwin wrote: > > On Wednesday 08 April 2009 3:37:38 pm Diego Depaoli wrote: > > > On Tue, Apr 7, 2009 at 4:26 PM, John Baldwin > > wrote: > > > > On Monday 06 April 2009 5:02:53 pm Diego Depaoli wrote: > > > >> And finally... > > > >> if I enable ahci in bios the system won't boot  with btx > > > >> halted. Ctrl+alt+del is the only allowed action. > > > >> > > > >> Yes... it's a low cost motherboard, but I'm a bit confused. > > > > > > > > What OS release are you running? > > > > > > 8.0-CURRENT FreeBSD 8.0-CURRENT #19: Sun Apr 5 02:25:34 CEST > > > 2009 FreeBSD version 800074 > > > > Very odd, can you get a copy of the BTX fault output? > > As I said earlier, I have a similar board and this is what I got: > > int=0000000d err=00000000 efl=00030002 eip=000001b1 > eax=00000011 ebx=00000002 ecx=00009d82 edx=0009dbc8 > esi=000003f0 edi=00000368 ebp=000003a8 esp=00000362 > cs=cf00 ds=0040 es=1400 fs=0000 gs=0000 ss=9d82 > cs:eip=2e 0f 01 16 7d 00 0f 20-c0 0c 01 0f 22 c0 eb 00 > b8 08 00 8e d8 8e c0 8e-d0 66 2e a1 54 00 66 8b > ss:esp=3f 00 c0 96 00 00 11 00-00 00 00 14 40 00 02 2f > 46 00 02 00 00 00 f0 03-00 00 a8 03 00 00 94 03 > > The following is the disassembled code: > > 0: 2e 0f 01 16 lgdtl %cs:(%esi) > 4: 7d 00 jge 0x6 > 6: 0f 20 c0 mov %cr0,%eax > 9: 0c 01 or $0x1,%al > b: 0f 22 c0 mov %eax,%cr0 > e: eb 00 jmp 0x10 > 10: b8 08 00 8e d8 mov $0xd88e0008,%eax > 15: 8e c0 mov %eax,%es > 17: 8e d0 mov %eax,%ss > 19: 66 2e a1 54 00 66 8b mov %cs:0x8b660054,%ax Ouch, the following should be more likely disassembly: 0: 2e 0f 01 16 7d 00 lgdtl %cs:0x7d 6: 0f 20 c0 mov %cr0,%ax 9: 0c 01 or $0x1,%al b: 0f 22 c0 mov %ax,%cr0 e: eb 00 jmp 0x10 10: b8 08 00 mov $0x08,%ax 13: 8e d8 mov %ax,%ds 15: 8e c0 mov %ax,%es 17: 8e d0 mov %ax,%ss 19: 66 2e a1 54 00 mov %cs:0x54,%ax Jung-uk Kim From fbsdlist at src.cx Mon Apr 13 17:03:31 2009 From: fbsdlist at src.cx (Artem Belevich) Date: Mon Apr 13 17:23:01 2009 Subject: [patch] zfs livelock and thread priorities In-Reply-To: References: <49C2CFF6.8070608@egr.msu.edu> Message-ID: Tried your patch that used PRIBIO+{1,2} for priorities with -current r191008 and the kernel died with "spinlock held too long" panic. Actually, there apparently were two instances of panic on different cores.. Here's output of "alltrace" and "ps" after the crash: http://pastebin.com/f140f4596 I've reverted the change and kernel booted just fine. The box is quad-core with two ZFS pools -- one single-disk and another one is a two-disk mirror. Freebsd is installed on UFS partitions, ZFS is used for user stuff only. --Artem On Thu, Mar 19, 2009 at 5:19 PM, Ben Kelly wrote: > On Mar 19, 2009, at 7:06 PM, Adam McDougall wrote: >> >> I was really impressed with your diagnosis but didn't try your patch until >> this afternoon. ?I had not seen processes spin, but I have had zfs get stuck >> roughly every 2 days on a somewhat busy ftp/rsync server until I turned off >> zil again, then it was up for over 13 days when I decided to try this patch. >> ?This system boots from a ufs / and turns around to try mounting a zfs root >> over top, but the first time it stalled for a few minutes at the root mount >> and "gave up" with a spinlock held too long, second time same thing but I >> didn't wait long enough for the spinlock error. Then I tried a power cycle >> just because, and the next two tries I got a page fault kernel panic. ?I'd >> try to give more details but right now im trying to get the server back up >> with a livecd because I goofed and don't have an old kernel to fall back on. >> ?Just wanted to let you know, and thanks for getting as far as you did! > > Ouch! ?Sorry you ran into that. > > I haven't seen these problems, but I keep my root partition on UFS and only > use zfs for /usr, /var, etc. ?Perhaps that explains the difference in > behavior. > > You could try changing the patch to use lower priorities. ?To do this change > compat/opensolaris/sys/proc.h so that it reads: > > ?#define ? ? ? ?minclsyspri ? ? PRI_MAX_REALTIME > ?#define ? ? ? ?maxclsyspri ? ?(PRI_MAX_REALTIME - 4) > > This compiles and runs on my machine. ?The theory here is that other kernel > threads will be able to run as they used to, but the zfs threads will still > be fixed relative to one another. ?Its really just a stab in the dark, > though. ?I don't have any experience with the "zfs mounted on top of ufs > root" configuration. ?If this works we should try to see if we can replace > PRI_MAX_REALTIME with PRI_MAX_KERN so that the zfs kernel threads run in the > kernel priority range. > > If you could get a stack trace of the kernel panic that would be helpful. > ?Also, if you have console access, can you break to debugger during the boot > spinlock hang and get a backtrace of the blocked process? > > If you want to compare other aspects of your environment to mine I uploaded > a bunch of info here: > > ?http://www.wanderview.com/svn/public/misc/zfs_livelock > > Finally, I'm CC'ing the list and some other people so they are aware that > the patch runs the risk of a panic. > > I hope that helps. > > - Ben > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > From bms at incunabulum.net Mon Apr 13 19:05:49 2009 From: bms at incunabulum.net (Bruce Simpson) Date: Mon Apr 13 19:46:10 2009 Subject: Flash10, with up to date current, not even recoginized with about:plugins. In-Reply-To: <20090413054500.1241102uwgs74khc@econet.encontacto.net> References: <20090413054500.1241102uwgs74khc@econet.encontacto.net> Message-ID: <49E3EF7A.1020107@incunabulum.net> eculp wrote: > > PS I did notice a userid (0) unknown with a couple of the linux-f8 > portw while installing them with portmaster and they installed fine. > IIRC gtk2 was one and scim was the other. JFYI: I found I had to use f9 for Flash 9 to run on 7.2-PRERELEASE. It still isn't 100% happy, in particular, plugin wrapper leaves processes lying around, and subsequent invocations can have problems doing anything at all; e.g. the first invocation running a YouTube video will work, but after that, it hangs. Firefox continues to run, but Flash does not work. From admin at lissyara.su Mon Apr 13 22:08:01 2009 From: admin at lissyara.su (Alex Keda) Date: Mon Apr 13 22:27:26 2009 Subject: NMI ISA 2c, EISA ff Message-ID: <49E41A2F.9080105@lissyara.su> I try install FreBSD; boot from USB hard drive on HP 2133 (laptop) Boot not success: agp0: on host0 agp0: aperture size is 128M NMI ISA 2c, EISA ff NMI ... going to debugger [thread pid0 tid 100000 ] Stopped at pmap_remove+0x158: testl %eax,%eax db> If I do not unplug hard drive - reboot with 2-3 seconds If unplug - not reboot, but, 'db>' go to down - kind of press enter (~10-20 seconds period) System - i386, GENERIC, from yesterday sources From marcus at FreeBSD.org Mon Apr 13 23:17:50 2009 From: marcus at FreeBSD.org (Joe Marcus Clarke) Date: Mon Apr 13 23:24:18 2009 Subject: Panic in vfs_cache on i386 Message-ID: <1239689868.1304.209.camel@shumai.marcuscom.com> I'm seeing this panic on my -CURRENT i386 Tinderbox machine (using looped back NFS). The backtrace does not point to a line number in vfs_cache.c, and I can't figure out how atomic_cmpset_int is being called, so I'm confused as to exactly what is causing this. Any clues? FreeBSD fugu.marcuscom.com 8.0-CURRENT FreeBSD 8.0-CURRENT #20: Mon Apr 13 17:21:39 EDT 2009 gnome@fugu.marcuscom.com:/space/obj/usr/src/sys/FUGU i386 Fatal trap 12: page fault while in kernel mode cpuid = 1; apic id = 01 fault virtual address = 0x84 fault code = supervisor write, page not present instruction pointer = 0x20:0x80670cf0 stack pointer = 0x28:0xb9d59974 frame pointer = 0x28:0xb9d599a0 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 82240 (sh) panic: from debugger cpuid = 1 #0 doadump () at pcpu.h:246 #1 0x804958c9 in db_fncall (dummy1=1, dummy2=0, dummy3=-2137255936, dummy4=0xb9d59708 "\200??\204") at /usr/src/sys/ddb/db_command.c:548 #2 0x80495cc1 in db_command (last_cmdp=0x8094251c, cmd_table=0x0, dopager=1) at /usr/src/sys/ddb/db_command.c:445 #3 0x80495e1a in db_command_loop () at /usr/src/sys/ddb/db_command.c:498 #4 0x80497c5d in db_trap (type=12, code=0) at /usr/src/sys/ddb/db_main.c:229 #5 0x80629ef6 in kdb_trap (type=12, code=0, tf=0xb9d59934) at /usr/src/sys/kern/subr_kdb.c:534 #6 0x808666ef in trap_fatal (frame=0xb9d59934, eva=132) at /usr/src/sys/i386/i386/trap.c:917 #7 0x80866990 in trap_pfault (frame=0xb9d59934, usermode=0, eva=132) at /usr/src/sys/i386/i386/trap.c:839 #8 0x80867362 in trap (frame=0xb9d59934) at /usr/src/sys/i386/i386/trap.c:521 #9 0x8084b93b in calltrap () at /usr/src/sys/i386/i386/exception.s:165 #10 0x80670cf0 in cache_lookup (dvp=0x8a55a10c, vpp=0xb9d59b78, cnp=0xb9d59b8c) at atomic.h:153 #11 0x80670f93 in vfs_cache_lookup (ap=0xb9d59a40) at /usr/src/sys/kern/vfs_cache.c:869 #12 0x808736e6 in VOP_LOOKUP_APV (vop=0x8092a680, a=0xb9d59a40) at vnode_if.c:123 #13 0x80678351 in lookup (ndp=0xb9d59b60) at vnode_if.h:54 #14 0x806792ab in namei (ndp=0xb9d59b60) at /usr/src/sys/kern/vfs_lookup.c:256 #15 0x8068893b in kern_statat_vnhook (td=0x86085000, flag=0, fd=-100, path=0x33f02400
, pathseg=UIO_USERSPACE, sbp=0xb9d59c18, hook=0) at /usr/src/sys/kern/vfs_syscalls.c:2356 #16 0x80688aac in kern_statat (td=0x86085000, flag=0, fd=-100, path=0x33f02400
, pathseg=UIO_USERSPACE, sbp=0xb9d59c18) at /usr/src/sys/kern/vfs_syscalls.c:2337 #17 0x80688bf6 in kern_stat (td=0x86085000, path=0x33f02400
, pathseg=UIO_USERSPACE, sbp=0xb9d59c18) at /usr/src/sys/kern/vfs_syscalls.c:2329 #18 0x80688c9f in stat (td=0x86085000, uap=0xb9d59cf8) at /usr/src/sys/kern/vfs_syscalls.c:2298 #19 0x80866cd5 in syscall (frame=0xb9d59d38) at /usr/src/sys/i386/i386/trap.c:1066 #20 0x8084b9a0 in Xint0x80_syscall () at /usr/src/sys/i386/i386/exception.s:261 #21 0x00000033 in ?? () Previous frame inner to this frame (corrupt stack?) print *dvp $6 = {v_type = VDIR, v_tag = 0x808c518a "ufs", v_op = 0x8092a160, v_data = 0x8a1f707c, v_mount = 0x8531b500, v_nmntvnodes = { tqe_next = 0x8a554754, tqe_prev = 0x8a55a65c}, v_un = {vu_mount = 0x0, vu_socket = 0x0, vu_cdev = 0x0, vu_fifoinfo = 0x0, vu_yield = 0}, v_hashlist = {le_next = 0x8600d324, le_prev = 0x8503b170}, v_hash = 10739825, v_cache_src = {lh_first = 0x0}, v_cache_dst = { tqh_first = 0x0, tqh_last = 0x8a55a13c}, v_cache_dd = 0x86770120, v_cstart = 0, v_lasta = 0, v_lastw = 0, v_clen = 0, v_lock = {lock_object = { lo_name = 0x808c518a "ufs", lo_flags = 91947009, lo_data = 0, lo_witness = 0x0}, lk_lock = 1, lk_timo = 51, lk_pri = 80}, v_interlock = {lock_object = {lo_name = 0x808d15c1 "vnode interlock", lo_flags = 16973824, lo_data = 0, lo_witness = 0x0}, mtx_lock = 4}, v_vnlock = 0x8a55a164, v_holdcnt = 3, v_usecount = 3, v_iflag = 0, v_vflag = 0, v_writecount = 0, v_freelist = {tqe_next = 0x0, tqe_prev = 0x0}, v_bufobj = {bo_mtx = {lock_object = { lo_name = 0x808d15d1 "bufobj interlock", lo_flags = 16973824, lo_data = 0, lo_witness = 0x0}, mtx_lock = 4}, bo_clean = {bv_hd = { tqh_first = 0x0, tqh_last = 0x8a55a1c8}, bv_root = 0x0, bv_cnt = 0}, bo_dirty = {bv_hd = {tqh_first = 0x0, tqh_last = 0x8a55a1d8}, bv_root = 0x0, bv_cnt = 0}, bo_numoutput = 0, bo_flag = 0, bo_ops = 0x8091ab80, bo_bsize = 16384, bo_object = 0x8a6c245c, bo_synclist = {le_next = 0x0, le_prev = 0x0}, bo_private = 0x8a55a10c, __bo_vnode = 0x8a55a10c}, v_pollinfo = 0x0, v_label = 0x0, v_lockf = 0x0} print *vpp $7 = (struct vnode *) 0x0 print *cnp $9 = {cn_nameiop = 0, cn_flags = 83943748, cn_thread = 0x86085000, cn_cred = 0x85ad4d00, cn_lkflags = 2097152, cn_pnbuf = 0x8acf6400 "..", cn_nameptr = 0x8acf6400 "..", cn_namelen = 2, cn_consume = 0} Joe -- Joe Marcus Clarke FreeBSD GNOME Team :: gnome@FreeBSD.org FreeNode / #freebsd-gnome http://www.FreeBSD.org/gnome -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: This is a digitally signed message part Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20090414/d422e3db/attachment.pgp From ale at FreeBSD.org Tue Apr 14 03:16:49 2009 From: ale at FreeBSD.org (Alex Dupre) Date: Tue Apr 14 04:00:48 2009 Subject: xorg loops In-Reply-To: <49DFBAEF.1080904@freebsd.org> References: <49D8D03B.8090302@arcor.de> <3a142e750904050919l1388b559t9bbd751546e239e7@mail.gmail.com> <1238957462.1829.8.camel@balrog.2hip.net> <49D90363.6010602@arcor.de> <1238959921.1829.10.camel@balrog.2hip.net> <49DB573C.3020703@FreeBSD.org> <1239129677.1947.14.camel@balrog.2hip.net> <49DC5066.1010607@FreeBSD.org> <1239176118.1954.11.camel@balrog.2hip.net> <49DF49AD.30701@FreeBSD.org> <49DFBAEF.1080904@freebsd.org> Message-ID: <49E4628D.7060208@FreeBSD.org> Tim Kientzle ha scritto: >> Nope :-( I have the same symptoms without using kdm and without >> launching it from /etc/ttys. Actually the mouse doesn't work even if I >> kill moused. The only way to make it working is setting >> AllowEmptyInput to off, nothing else works. > > Are you running hald? Of course (even if I don't use it for anything): %ps ax | grep hal 1031 ?? Ss 0:00,44 /usr/local/sbin/hald 1035 ?? I 0:00,05 hald-runner 1039 ?? S 0:00,08 hald-addon-storage: no polling on /dev/fd0 because it is explicitly disabled (hald-addon-storage) 1041 ?? S 0:00,11 hald-addon-storage: /dev/cd0 (hald-addon-storage) 1418 p0 S+ 0:00,00 grep hal %ps ax | grep dbus 917 ?? Is 0:00,01 /usr/local/bin/dbus-daemon --system 1420 p0 RL+ 0:00,00 grep dbus > On my system: > > AllowEmptyInput hald Result > off enabled Mouse/keyboard delays/jerkiness > off disabled Works > on (default) enabled Works > on (default) disabled No mouse/keyboard On my system: AllowEmptyInput hald Result off enabled Works off disabled Works on (default) enabled No mouse on (default) disabled No mouse As said, KDM or simple X session doesn't care, /etc/ttys or command line doesn't care. I still haven't received an answer on the following doubt: is it normal that lshal / hal-device doesn't show any mouse? -- Alex Dupre From avg at icyb.net.ua Tue Apr 14 03:58:52 2009 From: avg at icyb.net.ua (Andriy Gapon) Date: Tue Apr 14 04:10:47 2009 Subject: NMI ISA 2c, EISA ff In-Reply-To: <49E41A2F.9080105@lissyara.su> References: <49E41A2F.9080105@lissyara.su> Message-ID: <49E46C57.7030306@icyb.net.ua> on 14/04/2009 08:07 Alex Keda said the following: > I try install FreBSD; boot from USB hard drive on HP 2133 (laptop) > Boot not success: > > agp0: on host0 > agp0: aperture size is 128M > NMI ISA 2c, EISA ff I am not an expert here, but I had the above message on flaky hardware. But, again, the same symptoms do not mean the same cause. > NMI ... going to debugger > [thread pid0 tid 100000 ] > Stopped at pmap_remove+0x158: testl %eax,%eax > db> > > If I do not unplug hard drive - reboot with 2-3 seconds > If unplug - not reboot, but, 'db>' go to down - kind of press enter > (~10-20 seconds period) > System - i386, GENERIC, from yesterday sources -- Andriy Gapon From ben at wanderview.com Tue Apr 14 08:50:29 2009 From: ben at wanderview.com (Ben Kelly) Date: Tue Apr 14 09:09:53 2009 Subject: [patch] zfs livelock and thread priorities In-Reply-To: References: <49C2CFF6.8070608@egr.msu.edu> Message-ID: <08D7DC2A-68BE-47B6-8D5D-5DE6B48F87E5@wanderview.com> On Apr 13, 2009, at 7:36 PM, Artem Belevich wrote: > Tried your patch that used PRIBIO+{1,2} for priorities with -current > r191008 and the kernel died with "spinlock held too long" panic. > Actually, there apparently were two instances of panic on different > cores.. > > Here's output of "alltrace" and "ps" after the crash: > http://pastebin.com/f140f4596 > > I've reverted the change and kernel booted just fine. > > The box is quad-core with two ZFS pools -- one single-disk and another > one is a two-disk mirror. Freebsd is installed on UFS partitions, ZFS > is used for user stuff only. Thanks for the report! I don't have a lot of time to look at this today, but it appears that there is a race condition on SMP machines when setting the priority immediately after the kproc is spawned. As a quick hack I tried adding a pause between the kproc_create() and the sched_prio(). Can you try this patch? http://www.wanderview.com/svn/public/misc/zfs_livelock/zfs_thread_priority.diff I'll try to take a closer look at this later in the week. Thanks! - Ben From freebsd-listen at fabiankeil.de Tue Apr 14 09:00:29 2009 From: freebsd-listen at fabiankeil.de (Fabian Keil) Date: Tue Apr 14 09:11:21 2009 Subject: svn commit: r190857 - head/sys/dev/kbdmux In-Reply-To: References: <200904082052.n38KqU9p075633@svn.freebsd.org> <20090412170335.5a8a3169@fabiankeil.de> Message-ID: <20090414180020.34b97378@fabiankeil.de> Maksim Yevmenkin wrote: > On Sun, Apr 12, 2009 at 8:03 AM, Fabian Keil > wrote: > > Maksim Yevmenkin wrote: > > > >> Author: emax > >> Date: Wed Apr ?8 20:52:30 2009 > >> New Revision: 190857 > >> URL: http://svn.freebsd.org/changeset/base/190857 > >> > >> Log: > >> ? Undo SVN rev 183283 > >> > >> ? Do not use Giant for kbdmux(4) locking. This is wrong and apparently > >> ? causing more problems than it solves. This will re-open the issue > >> ? where interrupt handlers may race with kbdmux(4) in polling mode. > >> ? Typical symptoms include (but not limited to) duplicated and/or > >> ? missing characters when low level console functions (such as gets) > >> ? are used while interrupts are enabled (for example geli password > >> ? prompt, mountroot prompt etc.) > >> > >> ? MFC after: ?3 days > >> > >> Modified: > >> ? head/sys/dev/kbdmux/kbdmux.c [...] > > Not even enabling the "visible characters" option helps > > because obviously backspace is broken too. > > if you do not need kbdmix(4) you might just want to disable it on your > system. i think it should help with your particular problem. Removing kbdmux from the kernel does indeed work around the problem. > > Before theses locks were introduces I worked around the problem > > with this gets() hack (which forced me to reduce the key entropy): > > http://www.fabiankeil.de/sourcecode/freebsd/gets-no-duplicates.diff > > and now I will simply revert your commit locally, but I assume I'm > > not the only geli user who prefers to be able to boot the system > > without local patches. > > if your primary keyboard is atkbd(4), you might want to try the > following patch. it is completely untested (i did not even compile > it), so be warned ... > > Index: atkbd.c > =================================================================== > --- atkbd.c (revision 190905) > +++ atkbd.c (working copy) > @@ -476,7 +476,7 @@ > static int > atkbd_intr(keyboard_t *kbd, void *arg) > { > - atkbd_state_t *state; > + atkbd_state_t *state = (atkbd_state_t *)kbd->kb_data; > int delay[2]; > int c; > > @@ -485,7 +485,6 @@ > * The keyboard was not detected before; > * it must have been reconnected! > */ > - state = (atkbd_state_t *)kbd->kb_data; > init_keyboard(state->kbdc, &kbd->kb_type, > kbd->kb_config); > KBD_FOUND_DEVICE(kbd); > @@ -497,6 +496,9 @@ > } > > if (KBD_IS_ACTIVE(kbd) && KBD_IS_BUSY(kbd)) { > + if (state->ks_polling) > + return 0; > + > /* let the callback function to process the input */ > (*kbd->kb_callback.kc_func)(kbd, KBDIO_KEYINPUT, > kbd->kb_callback.kc_arg); > It compiles alright but once the system is running the keyboard no longer works at all. I tested the patch with kbdmux already disabled, but I assume it doesn't make a difference. Anyway, I don't need kbdmux, so having to remove it is no problem. Thanks a lot. Fabian -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 196 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20090414/2c2ce9a7/signature.pgp From marcus at marcuscom.com Tue Apr 14 09:13:07 2009 From: marcus at marcuscom.com (Joe Marcus Clarke) Date: Tue Apr 14 09:58:37 2009 Subject: xorg loops In-Reply-To: <49E4628D.7060208@FreeBSD.org> References: <49D8D03B.8090302@arcor.de> <3a142e750904050919l1388b559t9bbd751546e239e7@mail.gmail.com> <1238957462.1829.8.camel@balrog.2hip.net> <49D90363.6010602@arcor.de> <1238959921.1829.10.camel@balrog.2hip.net> <49DB573C.3020703@FreeBSD.org> <1239129677.1947.14.camel@balrog.2hip.net> <49DC5066.1010607@FreeBSD.org> <1239176118.1954.11.camel@balrog.2hip.net> <49DF49AD.30701@FreeBSD.org> <49DFBAEF.1080904@freebsd.org> <49E4628D.7060208@FreeBSD.org> Message-ID: <1239725583.1304.213.camel@shumai.marcuscom.com> On Tue, 2009-04-14 at 12:16 +0200, Alex Dupre wrote: > Tim Kientzle ha scritto: > >> Nope :-( I have the same symptoms without using kdm and without > >> launching it from /etc/ttys. Actually the mouse doesn't work even if I > >> kill moused. The only way to make it working is setting > >> AllowEmptyInput to off, nothing else works. > > > > Are you running hald? > > Of course (even if I don't use it for anything): > > %ps ax | grep hal > 1031 ?? Ss 0:00,44 /usr/local/sbin/hald > 1035 ?? I 0:00,05 hald-runner > 1039 ?? S 0:00,08 hald-addon-storage: no polling on /dev/fd0 > because it is explicitly disabled (hald-addon-storage) > 1041 ?? S 0:00,11 hald-addon-storage: /dev/cd0 (hald-addon-storage) > 1418 p0 S+ 0:00,00 grep hal > %ps ax | grep dbus > 917 ?? Is 0:00,01 /usr/local/bin/dbus-daemon --system > 1420 p0 RL+ 0:00,00 grep dbus > > > On my system: > > > > AllowEmptyInput hald Result > > off enabled Mouse/keyboard delays/jerkiness > > off disabled Works > > on (default) enabled Works > > on (default) disabled No mouse/keyboard > > On my system: > > AllowEmptyInput hald Result > off enabled Works > off disabled Works > on (default) enabled No mouse > on (default) disabled No mouse > > As said, KDM or simple X session doesn't care, /etc/ttys or command line > doesn't care. > > I still haven't received an answer on the following doubt: is it normal > that lshal / hal-device doesn't show any mouse? No, this is not normal. Hal should always show a mouse, for example: udi = '/org/freedesktop/Hal/devices/psm_0' freebsd.device_file = '/dev/psm0' (string) freebsd.driver = 'psm' (string) freebsd.unit = 0 (0x0) (int) info.addons = {'hald-addon-mouse-sysmouse'} (string list) info.capabilities = {'input', 'input.mouse'} (string list) info.category = 'input.mouse' (string) info.parent = '/org/freedesktop/Hal/devices/atkbdc_0' (string) info.product = 'PS/2 Mouse' (string) info.subsystem = 'platform' (string) info.udi = '/org/freedesktop/Hal/devices/psm_0' (string) input.device = '/dev/sysmouse' (string) input.x11_driver = 'mouse' (string) platform.id = 'psm.0' (string) Joe > -- PGP Key : http://www.marcuscom.com/pgp.asc -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: This is a digitally signed message part Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20090414/0588c895/attachment.pgp From eculp at encontacto.net Tue Apr 14 10:18:39 2009 From: eculp at encontacto.net (eculp) Date: Tue Apr 14 11:03:10 2009 Subject: Flash10, with up to date current, not even recoginized with about:plugins. In-Reply-To: <49E3EF7A.1020107@incunabulum.net> References: <20090413054500.1241102uwgs74khc@econet.encontacto.net> <49E3EF7A.1020107@incunabulum.net> Message-ID: <20090414121834.16493y1mb7iqhegw@econet.encontacto.net> Quoting Bruce Simpson : > eculp wrote: >> >> PS I did notice a userid (0) unknown with a couple of the linux-f8 >> portw while installing them with portmaster and they installed >> fine. IIRC gtk2 was one and scim was the other. > > JFYI: > I found I had to use f9 for Flash 9 to run on 7.2-PRERELEASE. Hi Bruce, Would this be Flash 10 you are refering to? Flash 9 was working fine for me before updating to the *-f8-* ports and moving to flash 10. I am going to give f9 a try with falsh10 and see if I can at least get it recoginized and maybe work as you have. Thanks, ed > > It still isn't 100% happy, in particular, plugin wrapper leaves > processes lying around, and subsequent invocations can have problems > doing anything at all; e.g. the first invocation running a YouTube > video will work, but after that, it hangs. Firefox continues to run, > but Flash does not work. > From rdivacky at freebsd.org Tue Apr 14 10:20:57 2009 From: rdivacky at freebsd.org (Roman Divacky) Date: Tue Apr 14 11:03:53 2009 Subject: IO related interactivity regression in recent -current Message-ID: <20090414170043.GA51803@freebsd.org> hi in recent weeks I am observing sudden drop of interactivity which is related to IO. thats is - when one process does IO and another tries to issue some IO as well the second one is terribly starved. nice testcase is: long running compilation in 1 window pkg_version -vl "<" in another window the pkg_version takes A LONG time to finish example: (on idle system) witten ~# time pkg_version -vl "<" .... 21.336u 13.078s 0:32.88 104.6% 320+582k 0+0io 0pf+0w (on gmake -j2 compilation of llvm) witten ~# time pkg_version -vl "<" .... 23.275u 10.937s 3:20.62 17.0% 288+506k 186+0io 121pf+0w ie. it takes 7times takes that long to finish. can someone shed some light on this? confirm this? thnx roman -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 196 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20090414/549df41a/attachment.pgp From james-freebsd-current at jrv.org Tue Apr 14 10:59:03 2009 From: james-freebsd-current at jrv.org (James R. Van Artsdalen) Date: Tue Apr 14 11:14:39 2009 Subject: ata FLUSHCACHE timeout errors? Message-ID: <49E4CED7.2040206@jrv.org> FreeBSD bigback.housenet.jrv 8.0-CURRENT FreeBSD 8.0-CURRENT #0 r190917: Sat Apr 11 19:48:25 CDT 2009 james@bigback.housenet.jrv:/usr/obj/usr/src/sys/GENERIC amd64 I am getting many FLUSHCACHE timeout errors during "zfs recv" operations. kernel: ata3: reiniting channel .. kernel: ata3: channel HW reset time=0ms kernel: ata3: SATA connect time=0ms status=00000113 kernel: ata3: siiprb_issue_cmd time=504ms status=00050000 kernel: ata3: SIGNATURE=00000101 kernel: ata3: siiprb_reset devices=00000001 kernel: ata3: reinit done .. kernel: ad6: TIMEOUT - FLUSHCACHE48 retrying (1 retry left) The "disk" is a SATA hardware RAID with 256 MB of write-back cache. Looking at the ATA code is appears that the timeout for a FLUSHCACHE operation is five seconds (unless the disk is known to be spun down). Five seconds seems much too short in any case - I think the ATA spec allows the device to take 30 seconds. Has anyone seen this or looked into ATA timeouts? From matti.k at bigpond.net.au Tue Apr 14 06:49:44 2009 From: matti.k at bigpond.net.au (matti k) Date: Tue Apr 14 12:15:01 2009 Subject: Flash10, with up to date current, not even recoginized with about:plugins. In-Reply-To: <20090413054500.1241102uwgs74khc@econet.encontacto.net> References: <20090413054500.1241102uwgs74khc@econet.encontacto.net> Message-ID: <20090414203301.57209d43@platypus.freebsd.home> On Mon, 13 Apr 2009 05:45:00 -0500 eculp wrote: > I'm using up to date current > # uname -a > FreeBSD ed.local.net.mx 8.0-CURRENT FreeBSD 8.0-CURRENT #203: Sun > Apr 12 15:13:50 CDT 2009 > > Auto-install plugins from /root/.mozilla/plugins Looking for plugins > in /root/.mozilla/plugins Install > plugin /root/.mozilla/plugins/nppdf.so > into /root/.mozilla/plugins/npwrapper.nppdf.so > Try running nspluginwrapper as normal user. Cheers, Matti From franks at rudbek.com Tue Apr 14 11:44:59 2009 From: franks at rudbek.com (Steve Franks) Date: Tue Apr 14 12:16:41 2009 Subject: About bwi In-Reply-To: References: <49A701DF.5070109@lissyara.su> <3c1674c90902261300x6dd5f21bja58ecf214bcfb644@mail.gmail.com> <49A70508.20100@lissyara.su> Message-ID: <539c60b90904141124j839dd20qb20e3e14b05e6f97@mail.gmail.com> 2009/2/26 Sepherosa Ziehau : > On Fri, Feb 27, 2009 at 5:09 AM, Alex Keda wrote: >> Kip Macy ?????: >>> >>> Someone needs to be there to maintain it. To the best of my knowledge >>> no one appropriate has stepped forward. >>> >> >> And what exactly should be supported? >> He finished - nothing more to do. > > I actually didn't finish it (the finished part works well enough for > me on dfly for all of the 8 bcm cards I have) and I do not have enough > time to keep working on it. ?Several folks mailed me about what to do > next, I pointed them to the spec on the web, however, I didn't hear > from any of them after that. > >> >> no way to develop a driver. >> the new cards have to write a new driver. > > I based on following URL when I worked on the "old" driver: > http://bcm-specs.sipsolutions.net/ > > For newer parts you will need following one: > http://bcm-v4.sipsolutions.net/ > > Hope this will be useful to you. > > Best Regards, > sephe > > -- > Live Free or Die > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > If someone could give me a hand on where to stick the tgz into /usr/src and get started, I'll have a go...I've written alot of drivers for 8051-style toys, I'm not sure if I'm man enough for this, but I'd rather try and fail, then skip the attempt. If nothing else, a working bwi in ports would answer an awful lot of ndisgen emails... I've seen a number of posts around the web. Was this for stable or current? I really don't have a functional current box at the moment, but several stable boxes where ndis0 won't find my AP's... Just to add to the fun, my latest system is brand-new, so it's a mini-pci-express bwi; I assume if that works, it's going to incorporate alot of other new cards... Steve From andreast-list at fgznet.ch Tue Apr 14 11:49:23 2009 From: andreast-list at fgznet.ch (Andreas Tobler) Date: Tue Apr 14 12:17:47 2009 Subject: Panic in vfs_cache on i386 In-Reply-To: <1239689868.1304.209.camel@shumai.marcuscom.com> References: <1239689868.1304.209.camel@shumai.marcuscom.com> Message-ID: <49E4D5D1.2090504@fgznet.ch> Joe Marcus Clarke wrote: > I'm seeing this panic on my -CURRENT i386 Tinderbox machine (using > looped back NFS). The backtrace does not point to a line number in > vfs_cache.c, and I can't figure out how atomic_cmpset_int is being > called, so I'm confused as to exactly what is causing this. Any clues? > > FreeBSD fugu.marcuscom.com 8.0-CURRENT FreeBSD 8.0-CURRENT #20: Mon Apr 13 17:21:39 EDT 2009 gnome@fugu.marcuscom.com:/space/obj/usr/src/sys/FUGU i386 > > Fatal trap 12: page fault while in kernel mode > cpuid = 1; apic id = 01 > fault virtual address = 0x84 > fault code = supervisor write, page not present > instruction pointer = 0x20:0x80670cf0 > stack pointer = 0x28:0xb9d59974 > frame pointer = 0x28:0xb9d599a0 > code segment = base 0x0, limit 0xfffff, type 0x1b > = DPL 0, pres 1, def32 1, gran 1 > processor eflags = interrupt enabled, resume, IOPL = 0 > current process = 82240 (sh) > panic: from debugger > cpuid = 1 > > > #0 doadump () at pcpu.h:246 > #1 0x804958c9 in db_fncall (dummy1=1, dummy2=0, dummy3=-2137255936, dummy4=0xb9d59708 "\200??\204") at /usr/src/sys/ddb/db_command.c:548 > #2 0x80495cc1 in db_command (last_cmdp=0x8094251c, cmd_table=0x0, dopager=1) at /usr/src/sys/ddb/db_command.c:445 > #3 0x80495e1a in db_command_loop () at /usr/src/sys/ddb/db_command.c:498 > #4 0x80497c5d in db_trap (type=12, code=0) at /usr/src/sys/ddb/db_main.c:229 > #5 0x80629ef6 in kdb_trap (type=12, code=0, tf=0xb9d59934) at /usr/src/sys/kern/subr_kdb.c:534 > #6 0x808666ef in trap_fatal (frame=0xb9d59934, eva=132) at /usr/src/sys/i386/i386/trap.c:917 > #7 0x80866990 in trap_pfault (frame=0xb9d59934, usermode=0, eva=132) at /usr/src/sys/i386/i386/trap.c:839 > #8 0x80867362 in trap (frame=0xb9d59934) at /usr/src/sys/i386/i386/trap.c:521 > #9 0x8084b93b in calltrap () at /usr/src/sys/i386/i386/exception.s:165 > #10 0x80670cf0 in cache_lookup (dvp=0x8a55a10c, vpp=0xb9d59b78, cnp=0xb9d59b8c) at atomic.h:153 > #11 0x80670f93 in vfs_cache_lookup (ap=0xb9d59a40) at /usr/src/sys/kern/vfs_cache.c:869 > #12 0x808736e6 in VOP_LOOKUP_APV (vop=0x8092a680, a=0xb9d59a40) at vnode_if.c:123 > #13 0x80678351 in lookup (ndp=0xb9d59b60) at vnode_if.h:54 > #14 0x806792ab in namei (ndp=0xb9d59b60) at /usr/src/sys/kern/vfs_lookup.c:256 > #15 0x8068893b in kern_statat_vnhook (td=0x86085000, flag=0, fd=-100, path=0x33f02400
, pathseg=UIO_USERSPACE, sbp=0xb9d59c18, hook=0) at /usr/src/sys/kern/vfs_syscalls.c:2356 > #16 0x80688aac in kern_statat (td=0x86085000, flag=0, fd=-100, path=0x33f02400
, pathseg=UIO_USERSPACE, sbp=0xb9d59c18) at /usr/src/sys/kern/vfs_syscalls.c:2337 > #17 0x80688bf6 in kern_stat (td=0x86085000, path=0x33f02400
, pathseg=UIO_USERSPACE, sbp=0xb9d59c18) at /usr/src/sys/kern/vfs_syscalls.c:2329 > #18 0x80688c9f in stat (td=0x86085000, uap=0xb9d59cf8) at /usr/src/sys/kern/vfs_syscalls.c:2298 > #19 0x80866cd5 in syscall (frame=0xb9d59d38) at /usr/src/sys/i386/i386/trap.c:1066 > #20 0x8084b9a0 in Xint0x80_syscall () at /usr/src/sys/i386/i386/exception.s:261 > #21 0x00000033 in ?? () > Previous frame inner to this frame (corrupt stack?) > > print *dvp > $6 = {v_type = VDIR, v_tag = 0x808c518a "ufs", v_op = 0x8092a160, > v_data = 0x8a1f707c, v_mount = 0x8531b500, v_nmntvnodes = { > tqe_next = 0x8a554754, tqe_prev = 0x8a55a65c}, v_un = {vu_mount = 0x0, > vu_socket = 0x0, vu_cdev = 0x0, vu_fifoinfo = 0x0, vu_yield = 0}, > v_hashlist = {le_next = 0x8600d324, le_prev = 0x8503b170}, > v_hash = 10739825, v_cache_src = {lh_first = 0x0}, v_cache_dst = { > tqh_first = 0x0, tqh_last = 0x8a55a13c}, v_cache_dd = 0x86770120, > v_cstart = 0, v_lasta = 0, v_lastw = 0, v_clen = 0, v_lock = {lock_object = { > lo_name = 0x808c518a "ufs", lo_flags = 91947009, lo_data = 0, > lo_witness = 0x0}, lk_lock = 1, lk_timo = 51, lk_pri = 80}, > v_interlock = {lock_object = {lo_name = 0x808d15c1 "vnode interlock", > lo_flags = 16973824, lo_data = 0, lo_witness = 0x0}, mtx_lock = 4}, > v_vnlock = 0x8a55a164, v_holdcnt = 3, v_usecount = 3, v_iflag = 0, > v_vflag = 0, v_writecount = 0, v_freelist = {tqe_next = 0x0, > tqe_prev = 0x0}, v_bufobj = {bo_mtx = {lock_object = { > lo_name = 0x808d15d1 "bufobj interlock", lo_flags = 16973824, > lo_data = 0, lo_witness = 0x0}, mtx_lock = 4}, bo_clean = {bv_hd = { > tqh_first = 0x0, tqh_last = 0x8a55a1c8}, bv_root = 0x0, bv_cnt = 0}, > bo_dirty = {bv_hd = {tqh_first = 0x0, tqh_last = 0x8a55a1d8}, > bv_root = 0x0, bv_cnt = 0}, bo_numoutput = 0, bo_flag = 0, > bo_ops = 0x8091ab80, bo_bsize = 16384, bo_object = 0x8a6c245c, > bo_synclist = {le_next = 0x0, le_prev = 0x0}, bo_private = 0x8a55a10c, > __bo_vnode = 0x8a55a10c}, v_pollinfo = 0x0, v_label = 0x0, v_lockf = 0x0} > > print *vpp > $7 = (struct vnode *) 0x0 > > print *cnp > $9 = {cn_nameiop = 0, cn_flags = 83943748, cn_thread = 0x86085000, > cn_cred = 0x85ad4d00, cn_lkflags = 2097152, cn_pnbuf = 0x8acf6400 "..", > cn_nameptr = 0x8acf6400 "..", cn_namelen = 2, cn_consume = 0} I see something similar on an amd64 box. I can reproduce it while make -j4 buildworld. Andreas FreeBSD deuterium_fbsd.andreas.nets 8.0-CURRENT FreeBSD 8.0-CURRENT #1 r191065M: Tue Apr 14 19:55:16 CEST 2009 andreast@deuterium_fbsd.andreas.nets:/export/devel/obj/export/devel/src/sys/ANDREAST_amd64 amd64 Unread portion of the kernel message buffer: Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address = 0xd8 fault code = supervisor write data, page not present instruction pointer = 0x20:0xffffffff805d96f6 stack pointer = 0x28:0xfffffffe7e8aa6b0 frame pointer = 0x28:0xfffffffe7e8aa730 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 12576 (sh) panic: from debugger cpuid = 0 Uptime: 2m23s Physical memory: 2034 MB Dumping 187 MB: 172 156 140 124 108 92 76 60 44 28 12 #0 doadump () at pcpu.h:223 223 pcpu.h: No such file or directory. in pcpu.h (kgdb) bt #0 doadump () at pcpu.h:223 #1 0xffffffff80563209 in boot (howto=260) at /export/devel/src/sys/kern/kern_shutdown.c:420 #2 0xffffffff8056365c in panic (fmt=Variable "fmt" is not available. ) at /export/devel/src/sys/kern/kern_shutdown.c:576 #3 0xffffffff801cce47 in db_panic (addr=Variable "addr" is not available. ) at /export/devel/src/sys/ddb/db_command.c:478 #4 0xffffffff801cd251 in db_command (last_cmdp=0xffffffff80b97520, cmd_table=Variable "cmd_table" is not available. ) at /export/devel/src/sys/ddb/db_command.c:445 #5 0xffffffff801cd4a0 in db_command_loop () at /export/devel/src/sys/ddb/db_command.c:498 #6 0xffffffff801cf429 in db_trap (type=Variable "type" is not available. ) at /export/devel/src/sys/ddb/db_main.c:229 #7 0xffffffff80593265 in kdb_trap (type=12, code=0, tf=0xfffffffe7e8aa600) at /export/devel/src/sys/kern/subr_kdb.c:534 #8 0xffffffff80839e2d in trap_fatal (frame=0xfffffffe7e8aa600, eva=Variable "eva" is not available. ) at /export/devel/src/sys/amd64/amd64/trap.c:840 #9 0xffffffff8083a204 in trap_pfault (frame=0xfffffffe7e8aa600, usermode=0) at /export/devel/src/sys/amd64/amd64/trap.c:761 #10 0xffffffff8083ab18 in trap (frame=0xfffffffe7e8aa600) at /export/devel/src/sys/amd64/amd64/trap.c:487 #11 0xffffffff80815973 in calltrap () at /export/devel/src/sys/amd64/amd64/exception.S:223 ---Type to continue, or q to quit--- #12 0xffffffff805d96f6 in cache_lookup (dvp=0x0, vpp=0xfffffffe7e8aa970, cnp=0xfffffffe7e8aa998) at atomic.h:147 #13 0xffffffff805d9ac0 in vfs_cache_lookup (ap=Variable "ap" is not available. ) at /export/devel/src/sys/kern/vfs_cache.c:869 #14 0xffffffff80881640 in VOP_LOOKUP_APV (vop=0xffffffff80b6d180, a=0xfffffffe7e8aa810) at vnode_if.c:123 #15 0xffffffff805e0b2b in lookup (ndp=0xfffffffe7e8aa940) at vnode_if.h:54 #16 0xffffffff805e1b41 in namei (ndp=0xfffffffe7e8aa940) at /export/devel/src/sys/kern/vfs_lookup.c:256 #17 0xffffffff805f0adf in kern_statat_vnhook (td=0xffffff0032352a80, flag=Variable "flag" is not available. ) at /export/devel/src/sys/kern/vfs_syscalls.c:2356 #18 0xffffffff805f0ca5 in kern_statat (td=Variable "td" is not available. ) at /export/devel/src/sys/kern/vfs_syscalls.c:2337 #19 0xffffffff805f0e4a in stat (td=Variable "td" is not available. ) at /export/devel/src/sys/kern/vfs_syscalls.c:2298 #20 0xffffffff8083a476 in syscall (frame=0xfffffffe7e8aac90) at /export/devel/src/sys/amd64/amd64/trap.c:977 #21 0xffffffff80815c00 in Xfast_syscall () at /export/devel/src/sys/amd64/amd64/exception.S:364 #22 0x000000080099fcfc in ?? () Previous frame inner to this frame (corrupt stack?) From emax at freebsd.org Tue Apr 14 12:02:21 2009 From: emax at freebsd.org (Maksim Yevmenkin) Date: Tue Apr 14 12:23:24 2009 Subject: svn commit: r190857 - head/sys/dev/kbdmux In-Reply-To: <20090414180020.34b97378@fabiankeil.de> References: <200904082052.n38KqU9p075633@svn.freebsd.org> <20090412170335.5a8a3169@fabiankeil.de> <20090414180020.34b97378@fabiankeil.de> Message-ID: On Tue, Apr 14, 2009 at 9:00 AM, Fabian Keil wrote: > Maksim Yevmenkin wrote: > >> On Sun, Apr 12, 2009 at 8:03 AM, Fabian Keil >> wrote: >> > Maksim Yevmenkin wrote: >> > >> >> Author: emax >> >> Date: Wed Apr 8 20:52:30 2009 >> >> New Revision: 190857 >> >> URL: http://svn.freebsd.org/changeset/base/190857 >> >> >> >> Log: >> >> Undo SVN rev 183283 >> >> >> >> Do not use Giant for kbdmux(4) locking. This is wrong and apparently >> >> causing more problems than it solves. This will re-open the issue >> >> where interrupt handlers may race with kbdmux(4) in polling mode. >> >> Typical symptoms include (but not limited to) duplicated and/or >> >> missing characters when low level console functions (such as gets) >> >> are used while interrupts are enabled (for example geli password >> >> prompt, mountroot prompt etc.) >> >> >> >> MFC after: 3 days >> >> >> >> Modified: >> >> head/sys/dev/kbdmux/kbdmux.c > > [...] > >> > Not even enabling the "visible characters" option helps >> > because obviously backspace is broken too. >> >> if you do not need kbdmix(4) you might just want to disable it on your >> system. i think it should help with your particular problem. > > Removing kbdmux from the kernel does indeed work around the problem. > >> > Before theses locks were introduces I worked around the problem >> > with this gets() hack (which forced me to reduce the key entropy): >> > http://www.fabiankeil.de/sourcecode/freebsd/gets-no-duplicates.diff >> > and now I will simply revert your commit locally, but I assume I'm >> > not the only geli user who prefers to be able to boot the system >> > without local patches. >> >> if your primary keyboard is atkbd(4), you might want to try the >> following patch. it is completely untested (i did not even compile >> it), so be warned ... > > It compiles alright but once the system is running the keyboard > no longer works at all. I tested the patch with kbdmux already > disabled, but I assume it doesn't make a difference. hmmm, interesting, i do not see this. atkbd(4) is working just fine with and without kbdmux(4) for me in sinlge user, ddb and multiuser. > Anyway, I don't need kbdmux, so having to remove it is no problem. > Thanks a lot. ok thanks max From admin at lissyara.su Tue Apr 14 12:11:31 2009 From: admin at lissyara.su (Alex Keda) Date: Tue Apr 14 12:29:40 2009 Subject: NMI ISA 2c, EISA ff In-Reply-To: <49E46C57.7030306@icyb.net.ua> References: <49E41A2F.9080105@lissyara.su> <49E46C57.7030306@icyb.net.ua> Message-ID: <49E4DFF7.4040008@lissyara.su> Andriy Gapon ?????: > on 14/04/2009 08:07 Alex Keda said the following: >> I try install FreBSD; boot from USB hard drive on HP 2133 (laptop) >> Boot not success: >> >> agp0: on host0 >> agp0: aperture size is 128M >> NMI ISA 2c, EISA ff > > I am not an expert here, but I had the above message on flaky hardware. > But, again, the same symptoms do not mean the same cause. I boot from flash drive with custom kernel (7.1 based) and copy CURRENT to hard drive It not boot with same error > >> NMI ... going to debugger >> [thread pid0 tid 100000 ] >> Stopped at pmap_remove+0x158: testl %eax,%eax >> db> >> >> If I do not unplug hard drive - reboot with 2-3 seconds >> If unplug - not reboot, but, 'db>' go to down - kind of press enter >> (~10-20 seconds period) >> System - i386, GENERIC, from yesterday sources > > From ohartman at mail.zedat.fu-berlin.de Tue Apr 14 09:08:57 2009 From: ohartman at mail.zedat.fu-berlin.de (O. Hartmann) Date: Tue Apr 14 12:41:16 2009 Subject: Xorg/X11 driver Radeon: radeon vs. radeonhd, a mess! Message-ID: <49E4B516.2080901@mail.zedat.fu-berlin.de> On two boxes running FreeBSD 8.0-CURRENT/amd64 (both PCIe-basis) I utilise AMD/ATi RV770LE and RV730 based graphicsadapter. Both machines run the most recent FreeBSD 8.0-CURRENT and most recent X11 from ports (with all the subsequent packages). The box with the most powerful graphicsadapter is the lowest powerful box, equipted with a UP kernel, single core CPU, PCIe 1.1. The GPU is a RV770LE mounted on a MSI R4830T2D512, This box does only work properly with driver 'radeon', using driver 'radeonhd' results in a missing display adapter - means, driver connot find a valid graphics card. On my lab's box, a 4-core SMP box with a more modern P35 chipset I utilise a MSI R4760 graphics card, this uses a AMD/ATi RV730 chip as GPU. This box does only run with 'radeonhd' in a propper manner, using 'radeon' craches the box when shutting down/resetting (kill -1) Xorg (server) when rebooting or leaving windowmaker. Although 'radeonhd' works and 'radeon' not, using 'radeonhd' renders X unusable. Window movement is like a slideshow, firefox seems to sleep randomly, scrolling is a game for patient people. VESA driver is much faster than 'radeonhd' on this fast chipset! Well, xf86-video-radeonhd is at revision 1.2.5 and this one is, when believing what the Wiki says, under development and advisory of AMD itself. Why is it so bumpy and unwilling to recognize an RV770LE chipset? Does anyone has a hint or tip? It feels like a mess having two ATI drivers each one following different ways of development. What 'radeon' is capable of is missing in 'radeonhd' and vice versa. Regards, Oliver From admin at lissyara.su Tue Apr 14 12:22:42 2009 From: admin at lissyara.su (Alex Keda) Date: Tue Apr 14 13:04:14 2009 Subject: About bwi In-Reply-To: <539c60b90904141124j839dd20qb20e3e14b05e6f97@mail.gmail.com> References: <49A701DF.5070109@lissyara.su> <3c1674c90902261300x6dd5f21bja58ecf214bcfb644@mail.gmail.com> <49A70508.20100@lissyara.su> <539c60b90904141124j839dd20qb20e3e14b05e6f97@mail.gmail.com> Message-ID: <49E4E293.7000302@lissyara.su> Steve Franks ?????: > 2009/2/26 Sepherosa Ziehau : >> On Fri, Feb 27, 2009 at 5:09 AM, Alex Keda wrote: >>> Kip Macy ?????: >>>> Someone needs to be there to maintain it. To the best of my knowledge >>>> no one appropriate has stepped forward. >>>> >>> And what exactly should be supported? >>> He finished - nothing more to do. >> I actually didn't finish it (the finished part works well enough for >> me on dfly for all of the 8 bcm cards I have) and I do not have enough >> time to keep working on it. Several folks mailed me about what to do >> next, I pointed them to the spec on the web, however, I didn't hear >> from any of them after that. >> >>> no way to develop a driver. >>> the new cards have to write a new driver. >> I based on following URL when I worked on the "old" driver: >> http://bcm-specs.sipsolutions.net/ >> >> For newer parts you will need following one: >> http://bcm-v4.sipsolutions.net/ >> >> Hope this will be useful to you. >> >> Best Regards, >> sephe >> >> -- >> Live Free or Die >> _______________________________________________ >> freebsd-current@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-current >> To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" >> > > If someone could give me a hand on where to stick the tgz into > /usr/src and get started, I'll have a go...I've written alot of > drivers for 8051-style toys, I'm not sure if I'm man enough for this, > but I'd rather try and fail, then skip the attempt. If nothing else, > a working bwi in ports would answer an awful lot of ndisgen emails... http://paradox.lissyara.su/bwi.02.tar.bz2 - 7.x http://paradox.lissyara.su/bwi.02e.tar.bz2 - current but - it only for PCI (PCMCI) new card - need new driver. see http://paradox.lissyara.su/bwi.03e.tar.bz2 It not work (only detecting correct). need write code > > I've seen a number of posts around the web. Was this for stable or > current? I really don't have a functional current box at the moment, > but several stable boxes where ndis0 won't find my AP's... > > Just to add to the fun, my latest system is brand-new, so it's a > mini-pci-express bwi; I assume if that works, it's going to > incorporate alot of other new cards... > > Steve > From jhb at freebsd.org Tue Apr 14 12:30:56 2009 From: jhb at freebsd.org (John Baldwin) Date: Tue Apr 14 13:17:14 2009 Subject: AMD 780G chipset major issues 3/3 (btx) In-Reply-To: <200904131836.57686.jkim@FreeBSD.org> References: <83e5fb980904061402q73940f8at4ec4b8f821354320@mail.gmail.com> <200904131305.12605.jhb@freebsd.org> <200904131836.57686.jkim@FreeBSD.org> Message-ID: <200904141015.40280.jhb@freebsd.org> On Monday 13 April 2009 6:36:55 pm Jung-uk Kim wrote: > On Monday 13 April 2009 01:05 pm, John Baldwin wrote: > > On Wednesday 08 April 2009 3:37:38 pm Diego Depaoli wrote: > > > On Tue, Apr 7, 2009 at 4:26 PM, John Baldwin =20 > wrote: > > > > On Monday 06 April 2009 5:02:53 pm Diego Depaoli wrote: > > > >> And finally... > > > >> if I enable ahci in bios the system won't boot =A0with btx > > > >> halted. Ctrl+alt+del is the only allowed action. > > > >> > > > >> Yes... it's a low cost motherboard, but I'm a bit confused. > > > > > > > > What OS release are you running? > > > > > > 8.0-CURRENT FreeBSD 8.0-CURRENT #19: Sun Apr 5 02:25:34 CEST > > > 2009 FreeBSD version 800074 > > > > Very odd, can you get a copy of the BTX fault output? >=20 > As I said earlier, I have a similar board and this is what I got: >=20 > int=3D0000000d err=3D00000000 efl=3D00030002 eip=3D000001b1 > eax=3D00000011 ebx=3D00000002 ecx=3D00009d82 edx=3D0009dbc8 > esi=3D000003f0 edi=3D00000368 ebp=3D000003a8 esp=3D00000362 > cs=3Dcf00 ds=3D0040 es=3D1400 fs=3D0000 gs=3D0000 ss=3D9d82 > cs:eip=3D2e 0f 01 16 7d 00 0f 20-c0 0c 01 0f 22 c0 eb 00 > b8 08 00 8e d8 8e c0 8e-d0 66 2e a1 54 00 66 8b > ss:esp=3D3f 00 c0 96 00 00 11 00-00 00 00 14 40 00 02 2f > 46 00 02 00 00 00 f0 03-00 00 a8 03 00 00 94 03 >=20 > The following is the disassembled code: >=20 > 0: 2e 0f 01 16 lgdtl %cs:(%esi) Are you sure you are using the real mode BTX? This trap has PSL_VM set in= =20 eflags: #define PSL_VM 0x00020000 /* virtual 8086 mode bit */ which would indicate that you are still using the old boot code. (Perhaps = you=20 have a new loader but have not installed new boot blocks using bsdlabel?) =2D-=20 John Baldwin From nakal at web.de Tue Apr 14 14:18:40 2009 From: nakal at web.de (Martin) Date: Tue Apr 14 14:37:09 2009 Subject: Xorg/X11 driver Radeon: radeon vs. radeonhd, a mess! In-Reply-To: <49E4B516.2080901@mail.zedat.fu-berlin.de> References: <49E4B516.2080901@mail.zedat.fu-berlin.de> Message-ID: <20090414231839.46d634f2@zelda.local> Am Tue, 14 Apr 2009 18:08:54 +0200 schrieb "O. Hartmann" : > [...] Hi, if you have problems with the radeonhd driver, you should tell the guys who work at it. They are really nice and try to help everywhere. Subscribe there: http://lists.opensuse.org/radeonhd/ I am only using radeonhd, because it works for me on all cards I have. I noticed that window movement may get choppy, when you compile a new kernel (DRM) and don't recompile a fresh radeonhd driver. This happens especially when DRI is enabled for your xorg server. -- Martin From rmacklem at uoguelph.ca Tue Apr 14 17:19:03 2009 From: rmacklem at uoguelph.ca (Rick Macklem) Date: Tue Apr 14 17:45:11 2009 Subject: Panic in vfs_cache on i386 In-Reply-To: <1239689868.1304.209.camel@shumai.marcuscom.com> References: <1239689868.1304.209.camel@shumai.marcuscom.com> Message-ID: On Tue, 14 Apr 2009, Joe Marcus Clarke wrote: > I'm seeing this panic on my -CURRENT i386 Tinderbox machine (using > looped back NFS). The backtrace does not point to a line number in > vfs_cache.c, and I can't figure out how atomic_cmpset_int is being > called, so I'm confused as to exactly what is causing this. Any clues? > Only a clue. but I'd guess it's one of the SDT_PROBE()s. I think they us sx_xlock() and that uses atomic_cmpset_int(). I don't know anything about SDT_PROBE(), but I did notice that this one uses cn_nameptr, which I don't think is always null terminated. You could try commenting out the SDT_PROBE()s in cache_lookup() and see if it helps? rick - around line #440 in vfs_cache.c /* We failed to find an entry */ if (ncp == NULL) { ---> SDT_PROBE(vfs, namecache, lookup, miss, dvp, cnp->cn_nameptr, NULL, 0, 0); if ((cnp->cn_flags & MAKEENTRY) == 0) { nummisszap++; } else { nummiss++; } nchstats.ncs_miss++; goto unlock; } From jkim at FreeBSD.org Tue Apr 14 17:23:35 2009 From: jkim at FreeBSD.org (Jung-uk Kim) Date: Tue Apr 14 18:04:17 2009 Subject: AMD 780G chipset major issues 3/3 (btx) In-Reply-To: <200904141015.40280.jhb@freebsd.org> References: <83e5fb980904061402q73940f8at4ec4b8f821354320@mail.gmail.com> <200904131836.57686.jkim@FreeBSD.org> <200904141015.40280.jhb@freebsd.org> Message-ID: <200904142023.26679.jkim@FreeBSD.org> On Tuesday 14 April 2009 10:15 am, John Baldwin wrote: > Are you sure you are using the real mode BTX? This trap has PSL_VM > set in eflags: > > #define PSL_VM 0x00020000 /* virtual 8086 mode bit */ > > which would indicate that you are still using the old boot code. > (Perhaps you have a new loader but have not installed new boot > blocks using bsdlabel?) That is embarrassing... I thought I had the realmode boot block but I was wrong. I had a screwed-up bsdlabel from sysinstall at some point. When I did 'bsdlabel -B', it failed to install the boot block at all but I ignored the error message, I guess. :-( The bright side of this embarrassment is now I have warning-free bsdlabels on all partitions. ;-) Sorry for the noise. Jung-uk Kim From Cy.Schubert at komquats.com Tue Apr 14 17:41:41 2009 From: Cy.Schubert at komquats.com (Cy Schubert) Date: Tue Apr 14 18:16:28 2009 Subject: GDM Hanging Machine Message-ID: <200904150013.n3F0D7XW004721@cwsys.cwsent.com> I thought to post this here before spending a lot of time on this. I have a laptop which normally boots 7.2-PRERELEASE however I do have CURRENT on a USB drive where I'm working on some USB floppy drive code. When GDM starts the whole system hangs. Before digging into this too deeply myself, has anyone seen this before and is there a quick fix? The ports collection on that drive was built on a 7.2 system and copied to the CURRENT system. This may in fact be the root cause and if so the fix is a no brainer. -- Cheers, Cy Schubert FreeBSD UNIX: Web: http://www.FreeBSD.org e**(i*pi)+1=0 From trebestie at gmail.com Tue Apr 14 17:55:04 2009 From: trebestie at gmail.com (Diego Depaoli) Date: Tue Apr 14 18:19:00 2009 Subject: AMD 780G chipset major issues 3/3 (btx) In-Reply-To: <200904142023.26679.jkim@FreeBSD.org> References: <83e5fb980904061402q73940f8at4ec4b8f821354320@mail.gmail.com> <200904131836.57686.jkim@FreeBSD.org> <200904141015.40280.jhb@freebsd.org> <200904142023.26679.jkim@FreeBSD.org> Message-ID: <83e5fb980904141755l3cf99fbdy75c2cdece4b25904@mail.gmail.com> On Wed, Apr 15, 2009 at 2:23 AM, Jung-uk Kim wrote: > > That is embarrassing... ?I thought I had the realmode boot block but I > was wrong. ?I had a screwed-up bsdlabel from sysinstall at some > point. ?When I did 'bsdlabel -B', it failed to install the boot block > at all but I ignored the error message, I guess. :-( Unfortunately that doesn't solve for me. I have a drive (ad4, ad6) - ad4s1 -> windows - ad4s2 -> linux swap - ad4s3 -> linux - ad4s4 -> FreeBSD bootloader is managed through EasyBCD Not being an expert I gave bsdlabel -B ad4s4 (is the right command?) but after that I get the same result int=0000000d err=00000000 efl=00030002 eip=000001e8 eax=00000010 ebx=00000002 ecx=00009e42 edx=0009e7c8 esi=000003f0 edi=0000036e ebp=000003a8 esp=00000368 cs=cf00 ds=0040 es=1400 fs=0000 gs=0000 ss=9e42 cs:eip=0f 22 c0 2e 0f 01 16 85-00 0f 20 c0 0c 01 0f 22 c0 eb 00 b8 08 00 8e d8-8e c0 8e d0 66 2e a1 5c ss:esp=3f 00 c0 96 00 00 00 14-40 00 46 00 02 00 00 00 f0 03 00 00 a8 03 00 00-94 03 00 00 00 00 00 00 Where I'm wrong? Best regards -- Diego Depaoli From ben at wanderview.com Tue Apr 14 19:32:35 2009 From: ben at wanderview.com (Ben Kelly) Date: Tue Apr 14 20:14:58 2009 Subject: [patch] zfs livelock and thread priorities In-Reply-To: <08D7DC2A-68BE-47B6-8D5D-5DE6B48F87E5@wanderview.com> References: <49C2CFF6.8070608@egr.msu.edu> <08D7DC2A-68BE-47B6-8D5D-5DE6B48F87E5@wanderview.com> Message-ID: On Apr 14, 2009, at 11:50 AM, Ben Kelly wrote: > On Apr 13, 2009, at 7:36 PM, Artem Belevich wrote: >> Tried your patch that used PRIBIO+{1,2} for priorities with -current >> r191008 and the kernel died with "spinlock held too long" panic. >> Actually, there apparently were two instances of panic on different >> cores.. >> >> Here's output of "alltrace" and "ps" after the crash: >> http://pastebin.com/f140f4596 >> >> I've reverted the change and kernel booted just fine. >> >> The box is quad-core with two ZFS pools -- one single-disk and >> another >> one is a two-disk mirror. Freebsd is installed on UFS partitions, ZFS >> is used for user stuff only. > > Thanks for the report! > > I don't have a lot of time to look at this today, but it appears > that there is a race condition on SMP machines when setting the > priority immediately after the kproc is spawned. As a quick hack I > tried adding a pause between the kproc_create() and the > sched_prio(). Can you try this patch? > > http://www.wanderview.com/svn/public/misc/zfs_livelock/zfs_thread_priority.diff > > I'll try to take a closer look at this later in the week. Sorry for replying to my own e-mail, but I've updated the patch again with a less hackish approach. (At the same URL above.) I added a new kproc_create_priority() function to set the priority of the new thread before its first scheduled. This should avoid any SMP races with setting the priority from an external thread. If you would be willing to try the test again with this new patch I would appreciate it. Thanks! - Ben From fbsdlist at src.cx Tue Apr 14 21:35:12 2009 From: fbsdlist at src.cx (Artem Belevich) Date: Tue Apr 14 22:24:18 2009 Subject: [patch] zfs livelock and thread priorities In-Reply-To: References: <49C2CFF6.8070608@egr.msu.edu> <08D7DC2A-68BE-47B6-8D5D-5DE6B48F87E5@wanderview.com> Message-ID: I'll give it a try in a few days. I'll let you know how it went. BTW, now that you're tinkering with ZFS threads and priorities, whould you by any chance have any idea why zfs scrub is so painfully slow on -current? When I start scrub on my -stable box, it pretty much runs full speed -- I can see disks under load all the time. However on -current scrub seems to run in small bursts. Disks get busy for a second or so and then things get quiet for about five seconds or so and this pattern repeats over and over. --Artem On Tue, Apr 14, 2009 at 7:32 PM, Ben Kelly wrote: > On Apr 14, 2009, at 11:50 AM, Ben Kelly wrote: >> >> On Apr 13, 2009, at 7:36 PM, Artem Belevich wrote: >>> >>> Tried your patch that used PRIBIO+{1,2} for priorities with -current >>> r191008 and the kernel died with "spinlock held too long" panic. >>> Actually, there apparently were two instances of panic on different >>> cores.. >>> >>> Here's output of "alltrace" and "ps" after the crash: >>> http://pastebin.com/f140f4596 >>> >>> I've reverted the change and kernel booted just fine. >>> >>> The box is quad-core with two ZFS pools -- one single-disk and another >>> one is a two-disk mirror. Freebsd is installed on UFS partitions, ZFS >>> is used for user stuff only. >> >> Thanks for the report! >> >> I don't have a lot of time to look at this today, but it appears that >> there is a race condition on SMP machines when setting the priority >> immediately after the kproc is spawned. ?As a quick hack I tried adding a >> pause between the kproc_create() and the sched_prio(). ?Can you try this >> patch? >> >> >> ?http://www.wanderview.com/svn/public/misc/zfs_livelock/zfs_thread_priority.diff >> >> I'll try to take a closer look at this later in the week. > > Sorry for replying to my own e-mail, but I've updated the patch again with a > less hackish approach. ?(At the same URL above.) ?I added a new > kproc_create_priority() function to set the priority of the new thread > before its first scheduled. ?This should avoid any SMP races with setting > the priority from an external thread. > > If you would be willing to try the test again with this new patch I would > appreciate it. > > Thanks! > > - Ben > From ohartman at zedat.fu-berlin.de Tue Apr 14 23:57:12 2009 From: ohartman at zedat.fu-berlin.de (O. Hartmann) Date: Wed Apr 15 00:35:47 2009 Subject: Xorg/X11 driver Radeon: radeon vs. radeonhd, a mess! In-Reply-To: <20090414231839.46d634f2@zelda.local> References: <49E4B516.2080901@mail.zedat.fu-berlin.de> <20090414231839.46d634f2@zelda.local> Message-ID: <49E584F0.5030702@zedat.fu-berlin.de> Martin wrote: > Am Tue, 14 Apr 2009 18:08:54 +0200 > schrieb "O. Hartmann" : > >> [...] > > Hi, > > if you have problems with the radeonhd driver, you should tell the guys > who work at it. They are really nice and try to help everywhere. > > Subscribe there: > http://lists.opensuse.org/radeonhd/ > > I am only using radeonhd, because it works for me on all cards I have. > > I noticed that window movement may get choppy, when you compile a new > kernel (DRM) and don't recompile a fresh radeonhd driver. This happens > especially when DRI is enabled for your xorg server. > > -- > Martin As far as I know, radeonhd from ports doesn't work with DRI enabled on FreeBSD - so it doesn't work on my box either. I guess you're following the recommendations using the development brnach directly from GIT. Thank's for the hint with DRM. I recompiled kernel/world stuff recently but I also recompiled all video driver also. I will do this and check whether it woul help enabling/disabling drm.ko/radeon.ko (which are both loaded when booing the kernel). Regards, Oliver Hartmann From gary.jennejohn at freenet.de Wed Apr 15 02:38:32 2009 From: gary.jennejohn at freenet.de (Gary Jennejohn) Date: Wed Apr 15 02:51:03 2009 Subject: Xorg/X11 driver Radeon: radeon vs. radeonhd, a mess! In-Reply-To: <49E584F0.5030702@zedat.fu-berlin.de> References: <49E4B516.2080901@mail.zedat.fu-berlin.de> <20090414231839.46d634f2@zelda.local> <49E584F0.5030702@zedat.fu-berlin.de> Message-ID: <20090415113828.46075cdc@ernst.jennejohn.org> On Wed, 15 Apr 2009 06:55:44 +0000 "O. Hartmann" wrote: > Martin wrote: > > Am Tue, 14 Apr 2009 18:08:54 +0200 > > schrieb "O. Hartmann" : > > > >> [...] > > > > Hi, > > > > if you have problems with the radeonhd driver, you should tell the guys > > who work at it. They are really nice and try to help everywhere. > > > > Subscribe there: > > http://lists.opensuse.org/radeonhd/ > > > > I am only using radeonhd, because it works for me on all cards I have. > > > > I noticed that window movement may get choppy, when you compile a new > > kernel (DRM) and don't recompile a fresh radeonhd driver. This happens > > especially when DRI is enabled for your xorg server. > > > > -- > > Martin > > As far as I know, radeonhd from ports doesn't work with DRI enabled on > FreeBSD - so it doesn't work on my box either. I guess you're following > the recommendations using the development brnach directly from GIT. > Works for me on amd64 8-current. garyj:ernst:~:-bash:4> grep DRI /var/log/Xorg.0.log (II) Loading extension XFree86-DRI (II) Loading extension DRI2 (**) RADEONHD(0): Option "DRI" (II) RADEONHD(0): FB: Allocated DRI Back Buffer at offset 0x024B4000 (size = 0x00B13000) (II) RADEONHD(0): FB: Allocated DRI Depth Buffer at offset 0x02FC7000 (size = 0x00B13000) (II) RADEONHD(0): FB: Allocated DRI Textures at offset 0x03ADA000 (size = 0x0C400000) (II) RADEONHD(0): [DRI] installation complete (II) GLX: Initialized DRISWRAST GL provider for screen 0 garyj:ernst:~:-bash:5> ls -d /var/db/pkg/*radeon* drwxr-xr-x 2 root wheel 512 Apr 14 11:32 /var/db/pkg/xf86-video-radeonhd-devel-1.2.5.20090412 --- Gary Jennejohn From ohartman at zedat.fu-berlin.de Wed Apr 15 02:44:23 2009 From: ohartman at zedat.fu-berlin.de (O. Hartmann) Date: Wed Apr 15 03:10:43 2009 Subject: Xorg/X11 driver Radeon: radeon vs. radeonhd, a mess! In-Reply-To: <20090415113828.46075cdc@ernst.jennejohn.org> References: <49E4B516.2080901@mail.zedat.fu-berlin.de> <20090414231839.46d634f2@zelda.local> <49E584F0.5030702@zedat.fu-berlin.de> <20090415113828.46075cdc@ernst.jennejohn.org> Message-ID: <49E5AC1F.1040808@zedat.fu-berlin.de> Gary Jennejohn wrote: > On Wed, 15 Apr 2009 06:55:44 +0000 > "O. Hartmann" wrote: > >> Martin wrote: >>> Am Tue, 14 Apr 2009 18:08:54 +0200 >>> schrieb "O. Hartmann" : >>> >>>> [...] >>> Hi, >>> >>> if you have problems with the radeonhd driver, you should tell the guys >>> who work at it. They are really nice and try to help everywhere. >>> >>> Subscribe there: >>> http://lists.opensuse.org/radeonhd/ >>> >>> I am only using radeonhd, because it works for me on all cards I have. >>> >>> I noticed that window movement may get choppy, when you compile a new >>> kernel (DRM) and don't recompile a fresh radeonhd driver. This happens >>> especially when DRI is enabled for your xorg server. >>> >>> -- >>> Martin >> As far as I know, radeonhd from ports doesn't work with DRI enabled on >> FreeBSD - so it doesn't work on my box either. I guess you're following >> the recommendations using the development brnach directly from GIT. >> > > Works for me on amd64 8-current. > > garyj:ernst:~:-bash:4> grep DRI /var/log/Xorg.0.log > (II) Loading extension XFree86-DRI > (II) Loading extension DRI2 > (**) RADEONHD(0): Option "DRI" > (II) RADEONHD(0): FB: Allocated DRI Back Buffer at offset 0x024B4000 (size = 0x00B13000) > (II) RADEONHD(0): FB: Allocated DRI Depth Buffer at offset 0x02FC7000 (size = 0x00B13000) > (II) RADEONHD(0): FB: Allocated DRI Textures at offset 0x03ADA000 (size = 0x0C400000) > (II) RADEONHD(0): [DRI] installation complete > (II) GLX: Initialized DRISWRAST GL provider for screen 0 > garyj:ernst:~:-bash:5> ls -d /var/db/pkg/*radeon* > drwxr-xr-x 2 root wheel 512 Apr 14 11:32 /var/db/pkg/xf86-video-radeonhd-devel-1.2.5.20090412 > > --- > Gary Jennejohn As I mentioned (but not very clear), I do not use the development radeonhd driver. So I will test this. Thanks. Oliver From ohartman at zedat.fu-berlin.de Wed Apr 15 03:09:27 2009 From: ohartman at zedat.fu-berlin.de (O. Hartmann) Date: Wed Apr 15 03:42:22 2009 Subject: Xorg/X11 driver Radeon: radeon vs. radeonhd, a mess! In-Reply-To: <20090415113828.46075cdc@ernst.jennejohn.org> References: <49E4B516.2080901@mail.zedat.fu-berlin.de> <20090414231839.46d634f2@zelda.local> <49E584F0.5030702@zedat.fu-berlin.de> <20090415113828.46075cdc@ernst.jennejohn.org> Message-ID: <49E5B1FF.8090606@zedat.fu-berlin.de> Gary Jennejohn wrote: > On Wed, 15 Apr 2009 06:55:44 +0000 > "O. Hartmann" wrote: > >> Martin wrote: >>> Am Tue, 14 Apr 2009 18:08:54 +0200 >>> schrieb "O. Hartmann" : >>> >>>> [...] >>> Hi, >>> >>> if you have problems with the radeonhd driver, you should tell the guys >>> who work at it. They are really nice and try to help everywhere. >>> >>> Subscribe there: >>> http://lists.opensuse.org/radeonhd/ >>> >>> I am only using radeonhd, because it works for me on all cards I have. >>> >>> I noticed that window movement may get choppy, when you compile a new >>> kernel (DRM) and don't recompile a fresh radeonhd driver. This happens >>> especially when DRI is enabled for your xorg server. >>> >>> -- >>> Martin >> As far as I know, radeonhd from ports doesn't work with DRI enabled on >> FreeBSD - so it doesn't work on my box either. I guess you're following >> the recommendations using the development brnach directly from GIT. >> > > Works for me on amd64 8-current. > > garyj:ernst:~:-bash:4> grep DRI /var/log/Xorg.0.log > (II) Loading extension XFree86-DRI > (II) Loading extension DRI2 > (**) RADEONHD(0): Option "DRI" > (II) RADEONHD(0): FB: Allocated DRI Back Buffer at offset 0x024B4000 (size = 0x00B13000) > (II) RADEONHD(0): FB: Allocated DRI Depth Buffer at offset 0x02FC7000 (size = 0x00B13000) > (II) RADEONHD(0): FB: Allocated DRI Textures at offset 0x03ADA000 (size = 0x0C400000) > (II) RADEONHD(0): [DRI] installation complete > (II) GLX: Initialized DRISWRAST GL provider for screen 0 > garyj:ernst:~:-bash:5> ls -d /var/db/pkg/*radeon* > drwxr-xr-x 2 root wheel 512 Apr 14 11:32 /var/db/pkg/xf86-video-radeonhd-devel-1.2.5.20090412 > > Tried radeonhd-devel and failed also! When enabling DRI in config file, I see the XDM login box and the box crashes and freezes immediately. Without DRI radeonhd-devel is horrible slow when moving windows around - inacceptable. It doesn't matter whether EXA is enabled or not and the phenomenon ist the same as with the regular radeonhd-driver from xorg-drivers. I'm back with the VESA driver. From jhb at freebsd.org Wed Apr 15 05:38:52 2009 From: jhb at freebsd.org (John Baldwin) Date: Wed Apr 15 05:57:45 2009 Subject: AMD 780G chipset major issues 3/3 (btx) In-Reply-To: <83e5fb980904141755l3cf99fbdy75c2cdece4b25904@mail.gmail.com> References: <83e5fb980904061402q73940f8at4ec4b8f821354320@mail.gmail.com> <200904142023.26679.jkim@FreeBSD.org> <83e5fb980904141755l3cf99fbdy75c2cdece4b25904@mail.gmail.com> Message-ID: <200904150838.25099.jhb@freebsd.org> On Tuesday 14 April 2009 8:55:01 pm Diego Depaoli wrote: > On Wed, Apr 15, 2009 at 2:23 AM, Jung-uk Kim wrote: > > > > That is embarrassing... ?I thought I had the realmode boot block but I > > was wrong. ?I had a screwed-up bsdlabel from sysinstall at some > > point. ?When I did 'bsdlabel -B', it failed to install the boot block > > at all but I ignored the error message, I guess. :-( > > Unfortunately that doesn't solve for me. > I have a drive (ad4, ad6) > - ad4s1 -> windows > - ad4s2 -> linux swap > - ad4s3 -> linux > - ad4s4 -> FreeBSD > bootloader is managed through EasyBCD > Not being an expert I gave > bsdlabel -B ad4s4 > (is the right command?) > but after that I get the same result > > int=0000000d err=00000000 efl=00030002 eip=000001e8 > eax=00000010 ebx=00000002 ecx=00009e42 edx=0009e7c8 > esi=000003f0 edi=0000036e ebp=000003a8 esp=00000368 > cs=cf00 ds=0040 es=1400 fs=0000 gs=0000 ss=9e42 > cs:eip=0f 22 c0 2e 0f 01 16 85-00 0f 20 c0 0c 01 0f 22 > c0 eb 00 b8 08 00 8e d8-8e c0 8e d0 66 2e a1 5c > ss:esp=3f 00 c0 96 00 00 00 14-40 00 46 00 02 00 00 00 > f0 03 00 00 a8 03 00 00-94 03 00 00 00 00 00 00 This fault is with the old boot blocks still. 'bsdlabel -B ad4s4' should update the boot blocks correctly. I'm not sure why you are still getting the old code. Perhaps /boot/boot has not been updated? -- John Baldwin From gary.jennejohn at freenet.de Wed Apr 15 07:03:14 2009 From: gary.jennejohn at freenet.de (Gary Jennejohn) Date: Wed Apr 15 07:38:57 2009 Subject: Xorg/X11 driver Radeon: radeon vs. radeonhd, a mess! In-Reply-To: <49E5B1FF.8090606@zedat.fu-berlin.de> References: <49E4B516.2080901@mail.zedat.fu-berlin.de> <20090414231839.46d634f2@zelda.local> <49E584F0.5030702@zedat.fu-berlin.de> <20090415113828.46075cdc@ernst.jennejohn.org> <49E5B1FF.8090606@zedat.fu-berlin.de> Message-ID: <20090415160311.2e898844@ernst.jennejohn.org> On Wed, 15 Apr 2009 10:07:59 +0000 "O. Hartmann" wrote: > Gary Jennejohn wrote: > > On Wed, 15 Apr 2009 06:55:44 +0000 > > "O. Hartmann" wrote: > > > >> Martin wrote: > >>> Am Tue, 14 Apr 2009 18:08:54 +0200 > >>> schrieb "O. Hartmann" : > >>> > >>>> [...] > >>> Hi, > >>> > >>> if you have problems with the radeonhd driver, you should tell the guys > >>> who work at it. They are really nice and try to help everywhere. > >>> > >>> Subscribe there: > >>> http://lists.opensuse.org/radeonhd/ > >>> > >>> I am only using radeonhd, because it works for me on all cards I have. > >>> > >>> I noticed that window movement may get choppy, when you compile a new > >>> kernel (DRM) and don't recompile a fresh radeonhd driver. This happens > >>> especially when DRI is enabled for your xorg server. > >>> > >>> -- > >>> Martin > >> As far as I know, radeonhd from ports doesn't work with DRI enabled on > >> FreeBSD - so it doesn't work on my box either. I guess you're following > >> the recommendations using the development brnach directly from GIT. > >> > > > > Works for me on amd64 8-current. > > > > garyj:ernst:~:-bash:4> grep DRI /var/log/Xorg.0.log > > (II) Loading extension XFree86-DRI > > (II) Loading extension DRI2 > > (**) RADEONHD(0): Option "DRI" > > (II) RADEONHD(0): FB: Allocated DRI Back Buffer at offset 0x024B4000 (size = 0x00B13000) > > (II) RADEONHD(0): FB: Allocated DRI Depth Buffer at offset 0x02FC7000 (size = 0x00B13000) > > (II) RADEONHD(0): FB: Allocated DRI Textures at offset 0x03ADA000 (size = 0x0C400000) > > (II) RADEONHD(0): [DRI] installation complete > > (II) GLX: Initialized DRISWRAST GL provider for screen 0 > > garyj:ernst:~:-bash:5> ls -d /var/db/pkg/*radeon* > > drwxr-xr-x 2 root wheel 512 Apr 14 11:32 /var/db/pkg/xf86-video-radeonhd-devel-1.2.5.20090412 > > > > > > Tried radeonhd-devel and failed also! > > When enabling DRI in config file, I see the XDM login box and the box > crashes and freezes immediately. Without DRI radeonhd-devel is horrible > slow when moving windows around - inacceptable. It doesn't matter > whether EXA is enabled or not and the phenomenon ist the same as with > the regular radeonhd-driver from xorg-drivers. > > I'm back with the VESA driver. Hmm. Are the drm and radeondrm in your kernel up-to-date? Your posting was chopped by the first replier and I can't remember. Can't think of anything else. I personally don't use xdm/gdm/kdm. I just use startx. --- Gary Jennejohn From ohartman at zedat.fu-berlin.de Wed Apr 15 07:25:34 2009 From: ohartman at zedat.fu-berlin.de (O. Hartmann) Date: Wed Apr 15 08:05:22 2009 Subject: Xorg/X11 driver Radeon: radeon vs. radeonhd, a mess! In-Reply-To: <20090415160311.2e898844@ernst.jennejohn.org> References: <49E4B516.2080901@mail.zedat.fu-berlin.de> <20090414231839.46d634f2@zelda.local> <49E584F0.5030702@zedat.fu-berlin.de> <20090415113828.46075cdc@ernst.jennejohn.org> <49E5B1FF.8090606@zedat.fu-berlin.de> <20090415160311.2e898844@ernst.jennejohn.org> Message-ID: <49E5EE04.1050208@zedat.fu-berlin.de> Gary Jennejohn wrote: > On Wed, 15 Apr 2009 10:07:59 +0000 > "O. Hartmann" wrote: > >> Gary Jennejohn wrote: >>> On Wed, 15 Apr 2009 06:55:44 +0000 >>> "O. Hartmann" wrote: >>> >>>> Martin wrote: >>>>> Am Tue, 14 Apr 2009 18:08:54 +0200 >>>>> schrieb "O. Hartmann" : >>>>> >>>>>> [...] >>>>> Hi, >>>>> >>>>> if you have problems with the radeonhd driver, you should tell the guys >>>>> who work at it. They are really nice and try to help everywhere. >>>>> >>>>> Subscribe there: >>>>> http://lists.opensuse.org/radeonhd/ >>>>> >>>>> I am only using radeonhd, because it works for me on all cards I have. >>>>> >>>>> I noticed that window movement may get choppy, when you compile a new >>>>> kernel (DRM) and don't recompile a fresh radeonhd driver. This happens >>>>> especially when DRI is enabled for your xorg server. >>>>> >>>>> -- >>>>> Martin >>>> As far as I know, radeonhd from ports doesn't work with DRI enabled on >>>> FreeBSD - so it doesn't work on my box either. I guess you're following >>>> the recommendations using the development brnach directly from GIT. >>>> >>> Works for me on amd64 8-current. >>> >>> garyj:ernst:~:-bash:4> grep DRI /var/log/Xorg.0.log >>> (II) Loading extension XFree86-DRI >>> (II) Loading extension DRI2 >>> (**) RADEONHD(0): Option "DRI" >>> (II) RADEONHD(0): FB: Allocated DRI Back Buffer at offset 0x024B4000 (size = 0x00B13000) >>> (II) RADEONHD(0): FB: Allocated DRI Depth Buffer at offset 0x02FC7000 (size = 0x00B13000) >>> (II) RADEONHD(0): FB: Allocated DRI Textures at offset 0x03ADA000 (size = 0x0C400000) >>> (II) RADEONHD(0): [DRI] installation complete >>> (II) GLX: Initialized DRISWRAST GL provider for screen 0 >>> garyj:ernst:~:-bash:5> ls -d /var/db/pkg/*radeon* >>> drwxr-xr-x 2 root wheel 512 Apr 14 11:32 /var/db/pkg/xf86-video-radeonhd-devel-1.2.5.20090412 >>> >>> >> Tried radeonhd-devel and failed also! >> >> When enabling DRI in config file, I see the XDM login box and the box >> crashes and freezes immediately. Without DRI radeonhd-devel is horrible >> slow when moving windows around - inacceptable. It doesn't matter >> whether EXA is enabled or not and the phenomenon ist the same as with >> the regular radeonhd-driver from xorg-drivers. >> >> I'm back with the VESA driver. > > Hmm. Are the drm and radeondrm in your kernel up-to-date? Your posting > was chopped by the first replier and I can't remember. > > Can't think of anything else. > > I personally don't use xdm/gdm/kdm. I just use startx. > > --- > Gary Jennejohn The kernel modules 'radeon' and 'drm' are loaded via /boot/loader.conf when booting and they are up to date (I do a buildworld on a regular basis these days and it takes ~30 minutes for a quad core box). Even when not starting X via xdm, the box crashes immediately, freezes and is only 'revivable' by cold resetting. This happens with driver radeonhd and enabled DRI. Without DRI the radeonhd driver works, but moving a window looks like on Windooze when using standard VGA driver without acceleration (this is bot with EXA on or off) - scrolling and moving objects is really choppy. 'radeon' doesn't even show up anything, freezes the box as well as 'radeonhd', but no matter whether DRI enabled or not. At home I will test radeonhd-devel with the RV770LE chipset (here I have only RV730). The RV770LE seems not to be recognized by 'radeonhd', but works fine with 'radeon'. But in both cases, DRI enabled crashes the box. From zbeeble at gmail.com Wed Apr 15 09:02:12 2009 From: zbeeble at gmail.com (Zaphod Beeblebrox) Date: Wed Apr 15 09:23:44 2009 Subject: Xorg/X11 driver Radeon: radeon vs. radeonhd, a mess! In-Reply-To: <49E5EE04.1050208@zedat.fu-berlin.de> References: <49E4B516.2080901@mail.zedat.fu-berlin.de> <20090414231839.46d634f2@zelda.local> <49E584F0.5030702@zedat.fu-berlin.de> <20090415113828.46075cdc@ernst.jennejohn.org> <49E5B1FF.8090606@zedat.fu-berlin.de> <20090415160311.2e898844@ernst.jennejohn.org> <49E5EE04.1050208@zedat.fu-berlin.de> Message-ID: <5f67a8c40904150841h3398e86tafe7b8b442bffafd@mail.gmail.com> 2009/4/15 O. Hartmann > > The kernel modules 'radeon' and 'drm' are loaded via /boot/loader.conf when > booting and they are up to date (I do a buildworld on a regular basis these > days and it takes ~30 minutes for a quad core box). > > Even when not starting X via xdm, the box crashes immediately, freezes and > is only 'revivable' by cold resetting. This happens with driver radeonhd and > enabled DRI. Without DRI the radeonhd driver works, but moving a window > looks like on Windooze when using standard VGA driver without acceleration > (this is bot with EXA on or off) - scrolling and moving objects is really > choppy. > > 'radeon' doesn't even show up anything, freezes the box as well as > 'radeonhd', but no matter whether DRI enabled or not. > > At home I will test radeonhd-devel with the RV770LE chipset (here I have > only RV730). The RV770LE seems not to be recognized by 'radeonhd', but works > fine with 'radeon'. But in both cases, DRI enabled crashes the box. Here, I have radeonhd loaded (the -devel doesn't seem to be that different a version). I have the radeon and drm kernel modules loaded. My only problem was that I had no input devices (which seems a really dumb default). My card is a Saphire 4870 --- which I believe is a RV770 based card. From rnoland at FreeBSD.org Wed Apr 15 11:46:44 2009 From: rnoland at FreeBSD.org (Robert Noland) Date: Wed Apr 15 12:21:18 2009 Subject: GDM Hanging Machine In-Reply-To: <200904150013.n3F0D7XW004721@cwsys.cwsent.com> References: <200904150013.n3F0D7XW004721@cwsys.cwsent.com> Message-ID: <1239821135.2194.6.camel@balrog.2hip.net> On Tue, 2009-04-14 at 17:13 -0700, Cy Schubert wrote: > I thought to post this here before spending a lot of time on this. I have a > laptop which normally boots 7.2-PRERELEASE however I do have CURRENT on a > USB drive where I'm working on some USB floppy drive code. When GDM starts > the whole system hangs. Before digging into this too deeply myself, has > anyone seen this before and is there a quick fix? The ports collection on > that drive was built on a 7.2 system and copied to the CURRENT system. This > may in fact be the root cause and if so the fix is a no brainer. Does it hang after you attempt to login? If so, rebuild/reinstall fusefs-kmod. Marcus and I were both having an issue with that. robert. -- Robert Noland FreeBSD -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 196 bytes Desc: This is a digitally signed message part Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20090415/3af77136/attachment.pgp From marcus at freebsd.org Wed Apr 15 12:55:44 2009 From: marcus at freebsd.org (Joe Marcus Clarke) Date: Wed Apr 15 13:19:01 2009 Subject: GDM Hanging Machine In-Reply-To: <200904150013.n3F0D7XW004721@cwsys.cwsent.com> References: <200904150013.n3F0D7XW004721@cwsys.cwsent.com> Message-ID: <49E636DA.7050304@freebsd.org> Cy Schubert wrote: > I thought to post this here before spending a lot of time on this. I have a > laptop which normally boots 7.2-PRERELEASE however I do have CURRENT on a > USB drive where I'm working on some USB floppy drive code. When GDM starts > the whole system hangs. Before digging into this too deeply myself, has > anyone seen this before and is there a quick fix? The ports collection on > that drive was built on a 7.2 system and copied to the CURRENT system. This > may in fact be the root cause and if so the fix is a no brainer. I believe this is the case. A hal built in 7.X will not work properly in 8.X. It is very kernel-specific. Joe > > -- Joe Marcus Clarke FreeBSD GNOME Team :: gnome@FreeBSD.org FreeNode / #freebsd-gnome http://www.FreeBSD.org/gnome From mister.olli at googlemail.com Wed Apr 15 12:57:47 2009 From: mister.olli at googlemail.com (Mister Olli) Date: Wed Apr 15 13:19:18 2009 Subject: Page fault with r191077 as xen PV Message-ID: <1239825458.23277.13.camel@phoenix.blechhirn.net> hi. I just build a XEN pv kernel, based on svn revision 191077. When booting the kernel stops with a page-fault. ===================================================== virt-001 template_8-CURRENT # xm create -c 00_template_8-CURRENT.XENconfig Using config file "./00_template_8-CURRENT.XENconfig". Started domain template_8-CURRENT WARNING: loader(8) metadata is missing! GDB: no debug ports present KDB: debugger backends: ddb KDB: current backend: ddb Copyright (c) 1992-2009 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 is a registered trademark of The FreeBSD Foundation. FreeBSD 8.0-CURRENT #2 r191077M: Wed Apr 15 21:46:50 CEST 2009 root@template-8_CURRENT.blechhirn.net:/usr/obj/usr/src/sys/freebsd8_WITHOUT_WITNESS WARNING: WITNESS option enabled, expect reduced performance. Xen reported: 1600.059 MHz processor. Timecounter "ixen" frequency 1000000000 Hz quality 0 CPU: AMD Athlon(tm) MP 1900+ (1600.06-MHz 686-class CPU) Origin = "AuthenticAMD" Id = 0x662 Stepping = 2 Features=0x383fbff AMD Features=0xc0480800 real memory = 536870912 (512 MB) avail memory = 517857280 (493 MB) cpu=0 irq=0 vector=0 cpu=0 irq=0 vector=1 kbd0 at kbdmux0 xenbus0: on motherboard xc0: on motherboard Timecounters tick every 100.000 msec Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address = 0x0 fault code = supervisor read, page not present instruction pointer = 0x21:0x0 stack pointer = 0x29:0xc21a9cdc frame pointer = 0x29:0xc21a9cf8 code segment = base 0x0, limit 0xf67ff, type 0x1b = DPL 1, pres 1, def32 1, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 14 (xenwatch) [thread pid 14 tid 100017 ] Stopped at 0: *** error reading from address 0 *** db> xccncheckc:155 bxccncheckc:155 txccncheckc:155 Tracing pid 14 tid 100017 td 0xc22d9230 _end(0,c21a9d38,c0254672,32d,c23272a4,...) at 0xc2346a00 fork_exit(c01fccd0,0,c21a9d38) at fork_exit+0xb8 fork_trampoline() at fork_trampoline+0x8 --- trap 0, eip = 0, esp = 0xc21a9d70, ebp = 0 --- db> ========================= The output of 'bt' from the debugger is included. Regards, Olli From ivoras at freebsd.org Wed Apr 15 15:04:49 2009 From: ivoras at freebsd.org (Ivan Voras) Date: Wed Apr 15 15:34:11 2009 Subject: NMI ISA 2c, EISA ff In-Reply-To: <49E41A2F.9080105@lissyara.su> References: <49E41A2F.9080105@lissyara.su> Message-ID: Alex Keda wrote: > I try install FreBSD; boot from USB hard drive on HP 2133 (laptop) > Boot not success: > > agp0: on host0 > agp0: aperture size is 128M > NMI ISA 2c, EISA ff NMIs are most commonly caused by memory errors (but could be other types of hardware errors). -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 258 bytes Desc: OpenPGP digital signature Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20090415/41e99b0f/signature.pgp From trebestie at gmail.com Wed Apr 15 16:27:54 2009 From: trebestie at gmail.com (Diego Depaoli) Date: Wed Apr 15 16:48:46 2009 Subject: AMD 780G chipset major issues 3/3 (btx) In-Reply-To: <200904150838.25099.jhb@freebsd.org> References: <83e5fb980904061402q73940f8at4ec4b8f821354320@mail.gmail.com> <200904142023.26679.jkim@FreeBSD.org> <83e5fb980904141755l3cf99fbdy75c2cdece4b25904@mail.gmail.com> <200904150838.25099.jhb@freebsd.org> Message-ID: <83e5fb980904151627k726294deoe8feba8c0b7d5167@mail.gmail.com> On Wed, Apr 15, 2009 at 2:38 PM, John Baldwin wrote: > > This fault is with the old boot blocks still. 'bsdlabel -B ad4s4' should > update the boot blocks correctly. I'm not sure why you are still getting the > old code. Perhaps /boot/boot has not been updated? I remaked world/kernel. Almost all files in /boot have same date/time. That's the output of bsdlabel -B ad4s4 partition a: offset past end of unit partition a: partition extends past end of unit partition b: offset past end of unit partition b: partition extends past end of unit partition c: offset past end of unit partition c: partition extends past end of unit