Re: Removing all ZFS support from boot process
On Fri, 11 Feb 2011, Mark Powell wrote: MP> > This is before the kernel boots, correct? MP> MP> Yep. MP> MP> > Can you take a picture of where it hangs? (you will have to host it MP> > somewhere though, as the list will reject non text attachments). MP> MP> Here you go: MP> MP> http://galatea.salford.ac.uk/aix502/11022011448.jpg MP> http://galatea.salford.ac.uk/aix502/11022011449.jpg MP> MP> The spinning char can seemingly be in any position when it crashes. It MP> took 5 attempts that time to get to the beastie menu. A friend of mine stepped into similar trouble a week or two ago. His problem disappears after updating IPMI (sic!) BIOS. Maybe it's somehow relevant to you too... -- Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] [ FreeBSD committer: ma...@freebsd.org ] -------- *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- ma...@rinet.ru *** ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
LSI SAS 2008 (mfi) on SuperMicro X8SI6-F
Dear colleagues, are there any success stories with using SuperMicro LSI SAS with stable/8 ? I tried mfi drivers sources from LSI site (had to add one #include to make kdump compilation happy) with no success pciconf info is none@pci0:0:2:0:class=0x010700 card=0x00721000 chip=0x00721000 rev=0x02 hdr=0x00 vendor = 'LSI Logic (Was: Symbios Login, NCR)' class = mass storage subclass = SAS Thanks in advance! -- Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] [ FreeBSD committer: ma...@freebsd.org ] ---- *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- ma...@rinet.ru *** ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: LSI SAS 2008 (mfi) on SuperMicro X8SI6-F
On Wed, 16 Feb 2011, Daniel Kalchev wrote: DK> I have sucessfully used that motherboard with FreeBSD 9 and the mps driver. DK> The mfi driver found on the LSI site does not support this controller. Ah that makes sense. I'm a bit reluctant to use -current on this particular machine, so I would discuss MFCing mps driver wirh ken@ Thank you for the info! (I planned to test -current at least just booting anyway) DK> PS: My experiments were with the X8DTL-6F motherboard and Supermicro chassis DK> with E16 expander. There is no reason the HBA chip in the single processor DK> motherboard to be different. My box is actually the same (846E1) -- Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] [ FreeBSD committer: ma...@freebsd.org ] ---- *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- ma...@rinet.ru *** ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: LSI SAS 2008 (mfi) on SuperMicro X8SI6-F
On Wed, 16 Feb 2011, Francois Tigeot wrote: FT> > DK> PS: My experiments were with the X8DTL-6F motherboard and Supermicro chassis FT> > DK> with E16 expander. There is no reason the HBA chip in the single processor FT> > DK> motherboard to be different. FT> > FT> > My box is actually the same (846E1) FT> FT> Not exactly: with Supermicro, E1 means a SAS 3 Gb/s backplane and E16 is FT> for SAS 6Gb/s Yea, you're right, it's E16 :) -- Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] [ FreeBSD committer: ma...@freebsd.org ] -------- *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- ma...@rinet.ru *** ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: LSI SAS 2008 (mfi) on SuperMicro X8SI6-F
On Wed, 16 Feb 2011, Damien Fleuriot wrote: DF> > DK> I have sucessfully used that motherboard with FreeBSD 9 and the mps driver. DF> > DK> The mfi driver found on the LSI site does not support this controller. DF> > DF> > Ah that makes sense. I'm a bit reluctant to use -current on this particular DF> > machine, so I would discuss MFCing mps driver wirh ken@ DF> > DF> DF> Careful, even when using the mps driver, we couldn't see the *logical* DF> drive here, with the h200 card. DF> DF> We could only use the drives by setting them to passthrough on the RAID DF> controller. I'm perfectly ready for this: it's target for ZFS ;-P -- Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] [ FreeBSD committer: ma...@freebsd.org ] -------- *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- ma...@rinet.ru *** ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: LSI SAS 2008 (mfi) on SuperMicro X8SI6-F
On Wed, 16 Feb 2011, Kenneth D. Merry wrote: KDM> > Ah that makes sense. I'm a bit reluctant to use -current on this particular KDM> > machine, so I would discuss MFCing mps driver wirh ken@ KDM> KDM> I have attached a patch against -stable, try it out and let me know whether KDM> it works. If so I'll go ahead and MFC it. I'm afraid something goes wrong at your side, at least in some files in sys/dev/mps, like Index: sys/dev/mps/mps_ioctl.h === --- sys/dev/mps/mps_ioctl.h (revision 212420) +++ sys/dev/mps/mps_ioctl.h (working copy) as there is no sys/dev/mps in stable/8 kernel sources -- Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] [ FreeBSD committer: ma...@freebsd.org ] -------- *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- ma...@rinet.ru *** ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: LSI SAS 2008 (mfi) on SuperMicro X8SI6-F
On Wed, 16 Feb 2011, Kenneth D. Merry wrote: KDM> > KDM> > Ah that makes sense. I'm a bit reluctant to use -current on this particular KDM> > KDM> > machine, so I would discuss MFCing mps driver wirh ken@ KDM> > KDM> KDM> > KDM> I have attached a patch against -stable, try it out and let me know whether KDM> > KDM> it works. If so I'll go ahead and MFC it. KDM> > KDM> > I'm afraid something goes wrong at your side, at least in some files in KDM> > sys/dev/mps, like KDM> > KDM> > Index: sys/dev/mps/mps_ioctl.h KDM> > === KDM> > --- sys/dev/mps/mps_ioctl.h (revision 212420) KDM> > +++ sys/dev/mps/mps_ioctl.h (working copy) KDM> > KDM> > as there is no sys/dev/mps in stable/8 kernel sources KDM> KDM> Whoops, svn diff doesn't do the right thing when there are multiple changes KDM> merged. KDM> KDM> I re-did the diffs manually, you should be able to do something like: KDM> KDM> cd src KDM> cat patch |patch -p4 well, this sequence creates mps-related files directly in src directory, but I managed to overcome this :) test reboot (remotely) said that at least machine tastes mps and single non-configured drive, but further testing is due. Thank you very much! -- Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] [ FreeBSD committer: ma...@freebsd.org ] *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- ma...@rinet.ru *** ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: 3TB disc and block alignment
On Thu, 17 Feb 2011, Daniel Kalchev wrote: DK> > > > da0: Fixed Direct Access SCSI-5 device DK> > > > da0: 2861588MB (5860533168 512 byte sectors: 255H 63S/T 364801C) DK> > DK> > Thanks -- is it also possible to have something like DK> > DK> > da0: 2861588MB (732566646 4096 byte sectors: 255H 63S/T 364801C) DK> > DK> According to Hitachi, this is an 512b drive. Yep. A friend of mine a couple of weeks ago was involved in testing 3T disks available now in RU: - Hitachi Deskstar 7K3000: HDS723030ALA640 - Seagate Barracuda XT: ST33000651AS - Western Digital Caviar Green: WD30EZRS-11J99B0 from which only the latter, according to the tests, uses 4k firmware sectors. -- Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] [ FreeBSD committer: ma...@freebsd.org ] -------- *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- ma...@rinet.ru *** ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: mps(4) driver (LSI 6Gb SAS) commited to stable/8
On Fri, 18 Feb 2011, Kenneth D. Merry wrote: KDM> I just merged the mps(4) driver to stable/8, for those of you with LSI 6Gb KDM> SAS hardware. [snip] Again, thank you very much Ken. I'm planning to stress test this on 846 case filled with 12 (yet) WD RE4 disks organized as raidz2, and will post the results. Any hints to particularly I/O stressing patterns? Out of my mind, I'm planning multiple parallel -j'ed builds, parallel tars, *SQL benchmarks -- what else could you suppose? -- Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] [ FreeBSD committer: ma...@freebsd.org ] ---- *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- ma...@rinet.ru *** ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: mps(4) driver (LSI 6Gb SAS) commited to stable/8
On Fri, 18 Feb 2011, Jeremy Chadwick wrote: JC> > KDM> I just merged the mps(4) driver to stable/8, for those of you with LSI 6Gb JC> > KDM> SAS hardware. JC> > JC> > [snip] JC> > JC> > Again, thank you very much Ken. I'm planning to stress test this on 846 case JC> > filled with 12 (yet) WD RE4 disks organized as raidz2, and will post the JC> > results. JC> > JC> > Any hints to particularly I/O stressing patterns? Out of my mind, I'm planning JC> > multiple parallel -j'ed builds, parallel tars, *SQL benchmarks -- what else JC> > could you suppose? JC> JC> Please be aware of a performance issue affecting certain models of WD JC> RE4 disks. Specifics are still sketchy, but you should read the thread JC> "immense delayed write to file system (ZFS and UFS2), performance JC> issues" in full to get an idea of the problem: Well, my disks are (possibly happily ;) not RE4-GP but real RE4 (yellow labels, Raid Edition Ready) But thanks, I'll take additional time to log smartctl data during the tests... -- Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] [ FreeBSD committer: ma...@freebsd.org ] *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- ma...@rinet.ru *** ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: mps(4) driver (LSI 6Gb SAS) commited to stable/8
On Fri, 18 Feb 2011, Kenneth D. Merry wrote: KDM> > KDM> I just merged the mps(4) driver to stable/8, for those of you with LSI 6Gb KDM> > KDM> SAS hardware. KDM> > KDM> > [snip] KDM> > KDM> > Again, thank you very much Ken. I'm planning to stress test this on 846 case KDM> > filled with 12 (yet) WD RE4 disks organized as raidz2, and will post the KDM> > results. KDM> > KDM> > Any hints to particularly I/O stressing patterns? Out of my mind, I'm planning KDM> > multiple parallel -j'ed builds, parallel tars, *SQL benchmarks -- what else KDM> > could you suppose? KDM> KDM> The best stress test I have found has been to just do a single sequential KDM> write stream with ZFS. i.e.: KDM> KDM> cd /path/to/zfs/pool KDM> dd if=/dev/zero of=foo bs=1M KDM> KDM> Just let it run for a long period of time and see what happens. Well, provided that I'm plannign to use ZFSv28 to be in place, wouldn't be /dev/random more appropriate? -- Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] [ FreeBSD committer: ma...@freebsd.org ] *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- ma...@rinet.ru *** ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: mps(4) driver (LSI 6Gb SAS) commited to stable/8
On Fri, 18 Feb 2011, Jeremy Chadwick wrote: JC> > KDM> The best stress test I have found has been to just do a single sequential JC> > KDM> write stream with ZFS. i.e.: JC> > KDM> JC> > KDM> cd /path/to/zfs/pool JC> > KDM> dd if=/dev/zero of=foo bs=1M JC> > KDM> JC> > KDM> Just let it run for a long period of time and see what happens. JC> > JC> > Well, provided that I'm plannign to use ZFSv28 to be in place, wouldn't be JC> > /dev/random more appropriate? JC> JC> No -- /dev/urandom maybe, but not /dev/random. /dev/urandom will also JC> induce significantly higher CPU load than /dev/zero will. Don't forget JC> that ZFS is a processor-centric (read: no offloading) system. We're not on Linux: root@beaver:/FreeBSD/src.8# l /dev/*random crw-rw-rw- 1 root wheel0, 23 Feb 15 13:50 /dev/random lrwxr-xr-x 1 root wheel 6 Feb 15 13:50 /dev/urandom@ -> random JC> I tend to try different block sizes (starting at bs=8k and working up to JC> bs=256k) for sequential benchmarks. The "sweet spot" on most disks I've JC> found is 64k. Otherwise use benchmarks/bonnie++. Ah yes, bonnie++ was on my list too, thanks for the reminder. -- Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] [ FreeBSD committer: ma...@freebsd.org ] *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- ma...@rinet.ru *** ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
gmirror start bug?
Dear Pawel, it seems thet gmirror is entering the endless loop if one inserted disk with previously configured mirror part in syncronyzing state: root@moose:/media/sata# gmirror list m0g Geom name: m0g State: STARTING Components: 2 Balance: split Slice: 4096 Flags: NONE GenID: 0 SyncID: 0 ID: 2992987948 Consumers: 1. Name: ad22g Mediasize: 272441875968 (254G) Sectorsize: 512 Mode: r1w1e1 State: NEW Priority: 0 Flags: SYNCHRONIZING GenID: 0 SyncID: 2 ID: 3619189671 root@moose:/media/sata# gmirror stop m0g ; gmirror clear ad22g Can't clear metadata on ad22g: Operation not permitted. gmirror: Not fully done. from kernel log: Mar 10 21:04:31 moose kernel: GEOM_MIRROR: Force device m0g start due to timeout. Mar 10 21:04:31 moose kernel: GEOM_MIRROR: Device m0g destroyed. Mar 10 21:04:35 moose kernel: GEOM_MIRROR: Force device m0g start due to timeout. Mar 10 21:04:35 moose kernel: GEOM_MIRROR: Device m0g destroyed. Mar 10 21:04:39 moose kernel: GEOM_MIRROR: Force device m0g start due to timeout. Mar 10 21:04:39 moose kernel: GEOM_MIRROR: Device m0g destroyed. ... In my case, a workaround was: detach broken disk, configure mirror with the same name (I did it over md), then gmirror clear ad22g -- but I suppose this situation should be somehow detected and loop broken. Thanks! -- Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] [ FreeBSD committer: ma...@freebsd.org ] *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- ma...@rinet.ru *** ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: SAS HBA LSI 9200-8e supported under 8.2?
On Mon, 21 Mar 2011, Denny Schierz wrote: DS> > LSI 9200-8e is based on the SAS2008 chip and the driver for that chip (mps) DS> > has recently been merged DS> > from current into stable but before 8.2-RELEASE. Therefore if you're using DS> > 8.2-RELEASE iso image to DS> > install FreeBSD on a SAS2008 system - you won't see any disks whatsoever. DS> > Unfortunately I can't find an 8.2-STABLE snapshot on the DS> > ftp.freebsd.orgeither which would have DS> > contained the mps driver. I hope someone who's capable of doing this can DS> > build one. DS> DS> thanks a lot for this way, but we don't need to install BSD on the SAS DS> disks :-) For the system itself we have to SATA disk (Raid1 gmirror or DS> raidz, if it isn't to complicated) and the SAS we need only for ISCSI DS> with ZFS. DS> DS> So maybe we need only to recompile the kernel or modules to get it DS> running. FWIW, (and you can find info about it in mailing list archives) I just built and about to out it into day-to-day use 8.2-stable system, working as big-just-in-case archive with sources from Mar1 based on SuperMicro case/mobo with LSI SAS2008 + LSI expander + 24 SATA RE4 disk bays. For now (and array is only half filled with disks) I'm very glad to have one-thread 500 MBps+ read stream from raidz2 array ;) Booting from mps (while I had to set up gmirror, as only 12 disks are exported to BIOS, hence very large raidz's are not allowed to boot from) was not a problem either. -- Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] [ FreeBSD committer: ma...@freebsd.org ] *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- ma...@rinet.ru *** ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
mps driver instability under stable/8
Dear Ken, I have SuperMicro Server with mps driver you managed, with 24 SATA disks under SAS x36 expander with large ZFS Sometimes, under random disk load such as daily find, it lost all its devices: [-- MARK -- Fri Apr 29 03:00:00 2011] mps0: IOC Fault 0x40005900, Resetting^M (pass20:mps0:0:22:0): SCSI command timeout on device handle 0x0020 SMID 442^M mps0: IOC Fault 0x40001500, Resetting^M (da19:mps0:0:21:0): SCSI command timeout on device handle 0x001f SMID 172^M (da19:mps0:0:21:0): SCSI command timeout on device handle 0x001f SMID 511^M (da20:mps0:0:20:0): SCSI command timeout on device handle 0x001e SMID 240^M .. (da4:mps0:0:0:0): SCSI command timeout on device handle 0x000a SMID 844^M (da22:mps0:0:23:0): SCSI command timeout on device handle 0x0021 SMID 713^M (da18:mps0:0:22:0): SCSI command timeout on device handle 0x0020 SMID 603^M and hangs there forever (in zio state). I've prepared debugging kernel with DDB and would be glad to help catch the situation. Thanks! -- Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] [ FreeBSD committer: ma...@freebsd.org ] *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- ma...@rinet.ru *** ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: mps driver instability under stable/8
On Mon, 2 May 2011, Kenneth D. Merry wrote: KDM> It looks like you have a SAS2008, with the 4.0 firmware. I think it would KDM> be worthwhile to upgrade to the 9.0 firmware. I know for sure there are KDM> issues with the 2.0 firmware, and I know the 9.0 firmware works fairly KDM> well. I don't know whether the 4.0 firmware has any severe issues, but it KDM> would be good to eliminate firmware bugs before we chase driver issues. [snip] KDM> Well, I think the first thing to do is upgrade the firmware and see if that KDM> fixes it. Well, I tried, and unfortunately I can not say that I'm happy after the upgrade. :( Particularly, adapter now takes *VERY* long time (>10 minutes) to initialize, and report as "ERROR" in BIOS utility (while seeing all 24 disks; however, it reports 8 x36 expanders instead of one). I can't boot the system off this array yet; will experiment further :( -- Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] [ FreeBSD committer: ma...@freebsd.org ] -------- *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- ma...@rinet.ru *** ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: mps driver instability under stable/8
On Tue, 3 May 2011, Dmitry Morozovsky wrote: DM> KDM> It looks like you have a SAS2008, with the 4.0 firmware. I think it would DM> KDM> be worthwhile to upgrade to the 9.0 firmware. I know for sure there are DM> KDM> issues with the 2.0 firmware, and I know the 9.0 firmware works fairly DM> KDM> well. I don't know whether the 4.0 firmware has any severe issues, but it DM> KDM> would be good to eliminate firmware bugs before we chase driver issues. DM> DM> [snip] DM> DM> KDM> Well, I think the first thing to do is upgrade the firmware and see if that DM> KDM> fixes it. DM> DM> Well, I tried, and unfortunately I can not say that I'm happy after the DM> upgrade. :( DM> DM> Particularly, adapter now takes *VERY* long time (>10 minutes) to initialize, DM> and report as "ERROR" in BIOS utility (while seeing all 24 disks; however, it DM> reports 8 x36 expanders instead of one). DM> DM> I can't boot the system off this array yet; will experiment further :( booted from USB stick, I have constantly repeating (ses3:mps0:0:25:0): lost device (ses3:mps0:0:25:0): removing device entry ses3 at mps0 bus 0 scbus0 target 25 lun 0 ses3: Fixed Enclosure Services SCSI-5 device ses3: 600.000MB/s transfers ses3: Command Queueing enabled ses3: SCSI-3 SES Device for different sesN, which are detected many times: at scbus0 target 0 lun 0 (da0,pass0) at scbus0 target 1 lun 0 (da1,pass1) at scbus0 target 2 lun 0 (da2,pass2) at scbus0 target 3 lun 0 (pass11,da4) at scbus0 target 4 lun 0 (pass12,da5) at scbus0 target 5 lun 0 (pass9,da3) at scbus0 target 24 lun 0 (pass5,ses3) at scbus0 target 25 lun 0 (pass19,ses5) at scbus0 target 26 lun 0 (pass10,ses4) at scbus0 target 27 lun 0 (pass14,ses7) at scbus0 target 33 lun 0 (pass13,ses6) at scbus0 target 39 lun 0 (pass3,ses0) at scbus0 target 45 lun 0 (pass4,ses1) at scbus0 target 51 lun 0 (pass8,ses2) at scbus0 target 55 lun 0 (pass15,da7) at scbus0 target 63 lun 0 (pass16,da8) at scbus0 target 71 lun 0 (pass17,da9) at scbus0 target 79 lun 0 (pass18,da10) at scbus0 target 87 lun 0 (pass6,da11) at scbus0 target 95 lun 0 (pass20,da12) at scbus0 target 103 lun 0 (pass21,da13) -- Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] [ FreeBSD committer: ma...@freebsd.org ] *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- ma...@rinet.ru *** ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: mps driver instability under stable/8
On Tue, 3 May 2011, Dmitry Morozovsky wrote: DM> DM> Well, I tried, and unfortunately I can not say that I'm happy after the DM> DM> upgrade. :( DM> DM> DM> DM> Particularly, adapter now takes *VERY* long time (>10 minutes) to initialize, DM> DM> and report as "ERROR" in BIOS utility (while seeing all 24 disks; however, it DM> DM> reports 8 x36 expanders instead of one). DM> DM> DM> DM> I can't boot the system off this array yet; will experiment further :( DM> DM> booted from USB stick, I have constantly repeating DM> DM> (ses3:mps0:0:25:0): lost device DM> (ses3:mps0:0:25:0): removing device entry DM> ses3 at mps0 bus 0 scbus0 target 25 lun 0 DM> ses3: Fixed Enclosure Services SCSI-5 device DM> ses3: 600.000MB/s transfers DM> ses3: Command Queueing enabled DM> ses3: SCSI-3 SES Device DM> DM> for different sesN, which are detected many times: DM> DM> at scbus0 target 0 lun 0 (da0,pass0) DM> at scbus0 target 1 lun 0 (da1,pass1) DM> at scbus0 target 2 lun 0 (da2,pass2) DM> at scbus0 target 3 lun 0 (pass11,da4) DM> at scbus0 target 4 lun 0 (pass12,da5) DM> at scbus0 target 5 lun 0 (pass9,da3) DM> at scbus0 target 24 lun 0 (pass5,ses3) DM> at scbus0 target 25 lun 0 (pass19,ses5) DM> at scbus0 target 26 lun 0 (pass10,ses4) DM> at scbus0 target 27 lun 0 (pass14,ses7) DM> at scbus0 target 33 lun 0 (pass13,ses6) DM> at scbus0 target 39 lun 0 (pass3,ses0) DM> at scbus0 target 45 lun 0 (pass4,ses1) DM> at scbus0 target 51 lun 0 (pass8,ses2) DM> at scbus0 target 55 lun 0 (pass15,da7) DM> at scbus0 target 63 lun 0 (pass16,da8) DM> at scbus0 target 71 lun 0 (pass17,da9) DM> at scbus0 target 79 lun 0 (pass18,da10) DM> at scbus0 target 87 lun 0 (pass6,da11) DM> at scbus0 target 95 lun 0 (pass20,da12) DM> at scbus0 target 103 lun 0 (pass21,da13) Well, using http://kb.lsi.com/KnowledgebaseArticle16414.aspx I downgraded to version 8-fixed, and at least topology errors disappear. Just booted successfully (errm, it was a few nervous hours, to be honest :) Now I have in verbose kernel messages mps0: port 0xc000-0xc0ff mem 0xfb43c000-0xfb43,0xfb44-0xfb47 irq 16 at device 0.0 on pci2 mps0: Reserved 0x4000 bytes for rid 0x14 type 3 at 0xfb43c000 mps0: Firmware: 08.00.00.00 mps0: IOCCapabilities: 185c mps0: attempting to allocate 1 MSI-X vectors (15 supported) msi: routing MSI-X IRQ 256 to local APIC 0 vector 49 mps0: using IRQ 256 for MSI-X mps0: [MPSAFE] mps0: [ITHREAD] Will see whether it helps. -- Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] [ FreeBSD committer: ma...@freebsd.org ] *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- ma...@rinet.ru *** ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: mps driver instability under stable/8
On Tue, 3 May 2011, Kenneth D. Merry wrote: KDM> Sorry you ran into all of those problems! Needless to say I haven't seen KDM> that with the 9.0 firmware in my environment, but then again I've got a KDM> different setup. I just postd comment on LSI kb forum, will see how they'd comment it. KDM> If the firmware doesn't fix it, we'll go down the path of trying to see why KDM> the IOC fault is happening. I'm staying tuned, while conserver is writing logs ;-) -- Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] [ FreeBSD committer: ma...@freebsd.org ] -------- *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- ma...@rinet.ru *** ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: mps driver instability under stable/8
On Tue, 10 May 2011, Daniel Kalchev wrote: DK> > Well, using DK> > http://kb.lsi.com/KnowledgebaseArticle16414.aspx DK> > I downgraded to version 8-fixed, and at least topology errors disappear. DK> > DK> Would this work with the Supermicro integrated LSI2008, like in X8DTH-6F? DK> Mine came with firmware version 7, is there instability to be expected? I suppose you can upgrade to "fixed" firmware from the URL above; at least, I'd been in mostly the same situation: SM server with onboard LSI and LSI expander, and so far flashing 8-fixed firmware is good for me, at least machine did not hang in find-related tasks as it were before... -- Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] [ FreeBSD committer: ma...@freebsd.org ] -------- *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- ma...@rinet.ru *** ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
stable/8-amd64 on ZFS as a vSphere backend
Dear colleagues, any particular hints to tune FreeBSD NFS server for efficient work as a VMware vSphere backend? For now, I set up 16G amd64 with ZFSv28, 4k recordsize and no other particular tuning, roundrobin lagg on 2 ems, mtu 9000. There are 4 WD RE3 1T disks as AHCI, on raid10 ZFS config. Local However, performance seems to be far from optimal (more deep testing is due, but at least average latency is too far, more than 100 ms). Local tests from zvol's (yes, that's not directly comparable but still) provide more than 500 MB/s on single/dual thread. Thanks in advance! -- Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] [ FreeBSD committer: ma...@freebsd.org ] ---- *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- ma...@rinet.ru *** ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
stable/8 nfsd: is it normal to have one worker regardless of -n setting?
Dear colleagues. just noticed that contemporary nfsd does not fork children in accordance to -n setting: stable/8: root@beaver:/usr/local/tb/scripts# pid nfs 1745 ?? Is 0:00.02 nfsd: master (nfsd) 1746 ?? S 0:03.29 nfsd: server (nfsd) root@beaver:/usr/local/tb/scripts# grep nfs_server_flags /etc/rc.conf nfs_server_flags="-u -t -n 4" stable/7: marck@kucha:~> pid nfs 654 ?? Is 0:00.01 nfsd: master (nfsd) 655 ?? I 0:05.64 nfsd: server (nfsd) 656 ?? I 0:00.00 nfsd: server (nfsd) 657 ?? I 0:00.00 nfsd: server (nfsd) 658 ?? I 0:00.00 nfsd: server (nfsd) marck@kucha:~> grep nfs_server_flags /etc/rc.conf marck@kucha:~> grep nfs_server_flags /etc/defaults/rc.conf nfs_server_flags="-u -t -n 4" # Flags to nfsd (if enabled). is it normal/expected? Thanks! -- Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] [ FreeBSD committer: ma...@freebsd.org ] -------- *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- ma...@rinet.ru *** ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: stable/8 nfsd: is it normal to have one worker regardless of -n setting?
On Sun, 31 Jul 2011, Dan Nelson wrote: > In the last episode (Aug 01), Dmitry Morozovsky said: > > just noticed that contemporary nfsd does not fork children in accordance > > to -n setting: > > > > stable/8: > > > > root@beaver:/usr/local/tb/scripts# pid nfs > > 1745 ?? Is 0:00.02 nfsd: master (nfsd) > > 1746 ?? S 0:03.29 nfsd: server (nfsd) > > root@beaver:/usr/local/tb/scripts# grep nfs_server_flags /etc/rc.conf > > nfs_server_flags="-u -t -n 4" > > They are threads now: > > # ps axw | grep nfsd > 1373 ?? Is 0:00.02 nfsd: master (nfsd) > 1374 ?? S 5:47.14 nfsd: server (nfsd) > # ps axwH | grep nfsd > 1373 ?? Is 0:00.02 nfsd: master (nfsd) > 1374 ?? S 1:25.79 nfsd: server (nfsd) > 1374 ?? S 1:26.65 nfsd: server (nfsd) > 1374 ?? S 1:27.67 nfsd: server (nfsd) > 1374 ?? S 1:27.04 nfsd: server (nfsd) Ah, yeah, how dumb is me, heh. Thank you for the pointer, and sorry for the noise. -- Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] [ FreeBSD committer: ma...@freebsd.org ] *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- ma...@rinet.ru *** ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
csup crash
Dear colleagues, I found csup is crashing on my building machine on some broken repo element, but cannot quickli realize what's the source of problem Any hints? Relevant info from gdb: #0 stream_open_buf (b=0x0) at /usr/src/usr.bin/csup/../../contrib/csup/stream.c:364 364 b->in = 0; [New Thread 800e0a900 (LWP 100725/csup)] [New Thread 800e0aac0 (LWP 100686/csup)] [New Thread 800e0ac80 (LWP 100548/csup)] [New Thread 800e0ae40 (LWP 100535/csup)] [New Thread 800e641c0 (LWP 100471/csup)] [New Thread 800e64380 (LWP 100443/csup)] [New Thread 800e041c0 (LWP 100446/initial thread)] (gdb) bt #0 stream_open_buf (b=0x0) at /usr/src/usr.bin/csup/../../contrib/csup/stream.c:364 #1 0x00411787 in rcsfile_getdeltatext (rf=0x80111ec00, d=0x801121880, buf_dest=0x7f1f9b18) at /usr/src/usr.bin/csup/../../contrib/csup/rcsfile.c:677 #2 0x00411715 in rcsfile_getdeltatext (rf=0x80111ec00, d=0x801121640, buf_dest=0x7f1f9c10) at /usr/src/usr.bin/csup/../../contrib/csup/rcsfile.c:658 #3 0x00412174 in rcsfile_write (rf=0x80111ec00, dest=0x8011099c0) at /usr/src/usr.bin/csup/../../contrib/csup/rcsfile.c:579 #4 0x00417d6c in updater_rcsedit (up=0x7f1f9f60, fup=0x801121d00, name=0x80111c402 "ports/graphics/Makefile,v", rcsopt=Variable "rcsopt" is not available. ) at /usr/src/usr.bin/csup/../../contrib/csup/updater.c:1688 #5 0x00419a59 in updater_batch (up=0x7f1f9f60, isfixups=0) at /usr/src/usr.bin/csup/../../contrib/csup/updater.c:773 #6 0x0041a1d1 in updater (arg=Variable "arg" is not available. ) at /usr/src/usr.bin/csup/../../contrib/csup/updater.c:237 #7 0x004158c4 in thread_start (data=Variable "data" is not available. ) at /usr/src/usr.bin/csup/../../contrib/csup/threads.c:169 #8 0x000800a224d1 in pthread_getprio () from /lib/libthr.so.3 #9 0x in ?? () Cannot access memory at address 0x7f1fa000 -- Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] [ FreeBSD committer: ma...@freebsd.org ] -------- *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- ma...@rinet.ru *** ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: csup crash
On Mon, 12 Sep 2011, John Baldwin wrote: > On Monday, September 12, 2011 2:01:16 am Dmitry Morozovsky wrote: > > Dear colleagues, > > > > I found csup is crashing on my building machine on some broken repo > > element, > > but cannot quickli realize what's the source of problem > > What OS version are you running? I wonder if you have this fix: it is on rather fresh stable/8: FreeBSD beaver.rinet.ru 8.2-STABLE FreeBSD 8.2-STABLE #5 r224908M: Tue Aug 16 15:43:23 MSD 2011 ma...@beaver.rinet.ru:/usr/obj/usr/src/sys/BEAVER amd64 so I suppose I'd have the fix you'd mentioned. I'm still have broken repo as a ZFS snapshot, so I'm ready to provide more info or test any fix you provide. Thanks! -- Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] [ FreeBSD committer: ma...@freebsd.org ] -------- *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- ma...@rinet.ru *** ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: csup crash
On Thu, 15 Sep 2011, Sergey Matveychuk wrote: > > > > I found csup is crashing on my building machine on some broken repo > > > > element, > > > > but cannot quickli realize what's the source of problem > > > > > > What OS version are you running? I wonder if you have this fix: > > > > it is on rather fresh stable/8: > > > > FreeBSD beaver.rinet.ru 8.2-STABLE FreeBSD 8.2-STABLE #5 r224908M: Tue Aug > > 16 > > 15:43:23 MSD 2011 ma...@beaver.rinet.ru:/usr/obj/usr/src/sys/BEAVER > > amd64 > > > > so I suppose I'd have the fix you'd mentioned. > > > > I'm still have broken repo as a ZFS snapshot, so I'm ready to provide more > > info or test any fix you provide. > > > > Have you found a broken file? What its content? Unfortunately not. I thought ports/graphics/Makefile,v (see gdb backtrace) was a touble source, but running csup on a clone of snaphot of crash state like csup -h cvsup2.ru.freebsd.org -b /FreeBSD-x -l /tmp/fbsd-cvs.lock -s ./cvs-supfile (here /FreeBSD-x is clone of /FreeBSD, with sup and ncvs inside; ./cvs-supfile is original with prefix=/FreeBSD-x/ncvs) does not crash, so I'm stumbled a bit :( -- Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] [ FreeBSD committer: ma...@freebsd.org ] *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- ma...@rinet.ru *** ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: csup crash
On Fri, 16 Sep 2011, Adrian Chadd wrote: > Does this fix it ? > > http://www.freebsd.org/cgi/query-pr.cgi?pr=bin/154954 Possibly. As I stated earlier, I can't reproduce the problem from ZFS repo/sup snapshot I beleived I should. On the second look, this particular change barely can fix my particular problem, as there was dereferencing bad pointer in patch phase, not fixup. Anyway, PR fix seemd to be needed. -- Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] [ FreeBSD committer: ma...@freebsd.org ] -------- *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- ma...@rinet.ru *** ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
tmpfs deadlock on stable/9
Dear colleagues, I have ports tinderbox runnign on stable/9-amd64, with working directories on tmpfs. I have two consecutive tmpfs deadlocks like root@beaver:/usr/local/tb/scripts# ps t2 PID TT STATTIME COMMAND 2337 2 Is 0:00.04 /bin/tcsh 3079 2 I0:00.01 sudo -sE 3260 2 I0:00.02 /bin/tcsh 20309 2 I+ 0:00.06 /bin/sh ./tc tinderbuild -nullfs -norebuild -b 9-i386-RiNet 27035 2 S+ 0:00.13 make PACKAGES=/usr/local/tb/packages/9-i386-RiNet -k -j1 all 46470 2 I+ 0:00.00 sh -ev 46471 2 I+ 0:00.01 /bin/sh /usr/local/tb/scripts/lib/portbuild 9-i386-RiNet 9-i386 RiNet -nullfs gsm-1.0.13.tbz /usr/ports/audio/gsm 46677 2 I+ 0:00.00 /bin/sh /buildscript /usr/ports/audio/gsm 2 46766 2 I+ 0:00.00 /pnohang 7200 /tmp/make.log4 gsm-1.0.13 make build 46767 2 I+ 0:00.02 make build 46768 2 I+ 0:00.00 /pnohang 7200 /tmp/make.log4 gsm-1.0.13 make build 46789 2 I+ 0:00.00 [sh] 46790 2 D+ 0:00.01 make -f Makefile -j4 all 46918 2 I+ 0:00.00 sh -ev 46926 2 I+ 0:00.00 sh -ev 46928 2 Z+ 0:00.09 46938 2 D+ 0:00.00 mv gsm_create.o ./src/gsm_create.o 46940 2 D+ 0:00.00 mv gsm_print.o ./src/gsm_print.o (this is parallel build, last 2 rm's are deadlocked on tmpfs) what kind of additional info should I send? I have debugging turned on in kernel, if it's needed. Thanks! -- Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] [ FreeBSD committer: ma...@freebsd.org ] ---- *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- ma...@rinet.ru *** ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: tmpfs deadlock on stable/9
On Wed, 7 Dec 2011, Kostik Belousov wrote: > > I have ports tinderbox runnign on stable/9-amd64, with working directories > > on > > tmpfs. I have two consecutive tmpfs deadlocks like > > > > root@beaver:/usr/local/tb/scripts# ps t2 > > PID TT STATTIME COMMAND > > 2337 2 Is 0:00.04 /bin/tcsh > > 3079 2 I0:00.01 sudo -sE > > 3260 2 I0:00.02 /bin/tcsh > > 20309 2 I+ 0:00.06 /bin/sh ./tc tinderbuild -nullfs -norebuild -b > > 9-i386-RiNet > > 27035 2 S+ 0:00.13 make PACKAGES=/usr/local/tb/packages/9-i386-RiNet > > -k > > -j1 all > > 46470 2 I+ 0:00.00 sh -ev > > 46471 2 I+ 0:00.01 /bin/sh /usr/local/tb/scripts/lib/portbuild > > 9-i386-RiNet 9-i386 RiNet -nullfs gsm-1.0.13.tbz /usr/ports/audio/gsm > > 46677 2 I+ 0:00.00 /bin/sh /buildscript /usr/ports/audio/gsm 2 > > 46766 2 I+ 0:00.00 /pnohang 7200 /tmp/make.log4 gsm-1.0.13 make build > > 46767 2 I+ 0:00.02 make build > > 46768 2 I+ 0:00.00 /pnohang 7200 /tmp/make.log4 gsm-1.0.13 make build > > 46789 2 I+ 0:00.00 [sh] > > 46790 2 D+ 0:00.01 make -f Makefile -j4 all > > 46918 2 I+ 0:00.00 sh -ev > > 46926 2 I+ 0:00.00 sh -ev > > 46928 2 Z+ 0:00.09 > > 46938 2 D+ 0:00.00 mv gsm_create.o ./src/gsm_create.o > > 46940 2 D+ 0:00.00 mv gsm_print.o ./src/gsm_print.o > > > > (this is parallel build, last 2 rm's are deadlocked on tmpfs) > > > > what kind of additional info should I send? I have debugging turned on in > > kernel, if it's needed. > http://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/kerneldebug-deadlocks.html > > No, I do not promise to look into it. It is available at http://bsd.woozle.net/tmpfs-lock-20111207.txt (~260k) BTW, at least some of the debugger commands referenced (show locks, show alllocks) are no longer exist Thank you! -- Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] [ FreeBSD committer: ma...@freebsd.org ] *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- ma...@rinet.ru *** ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: tmpfs deadlock on stable/9
On Wed, 7 Dec 2011, Kostik Belousov wrote: > > It is available at http://bsd.woozle.net/tmpfs-lock-20111207.txt (~260k) > > > > BTW, at least some of the debugger commands referenced (show locks, show > > alllocks) are no longer exist > This means that you do not have witness in your kernel. > Look at the reference I pointed you once more. Ah I see, my bad. I'll test this with WITNESS-enabled kernel tomorrow and return with updated results. -- Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] [ FreeBSD committer: ma...@freebsd.org ] -------- *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- ma...@rinet.ru *** ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: tmpfs deadlock on stable/9
On Thu, 8 Dec 2011, Dmitry Morozovsky wrote: > > > It is available at http://bsd.woozle.net/tmpfs-lock-20111207.txt (~260k) > > > > > > BTW, at least some of the debugger commands referenced (show locks, show > > > alllocks) are no longer exist > > This means that you do not have witness in your kernel. > > Look at the reference I pointed you once more. > > Ah I see, my bad. I'll test this with WITNESS-enabled kernel tomorrow and > return with updated results. Hmm, I'd rebuilt kernel with WITNESS/WITNESS_SKIPSPIN and can't reproduce this deadlock. Will try further. -- Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] [ FreeBSD committer: ma...@freebsd.org ] -------- *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- ma...@rinet.ru *** ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: tmpfs deadlock on stable/9
On Thu, 8 Dec 2011, Dmitry Morozovsky wrote: > > > > It is available at http://bsd.woozle.net/tmpfs-lock-20111207.txt (~260k) > > > > > > > > BTW, at least some of the debugger commands referenced (show locks, > > > > show > > > > alllocks) are no longer exist > > > This means that you do not have witness in your kernel. > > > Look at the reference I pointed you once more. > > > > Ah I see, my bad. I'll test this with WITNESS-enabled kernel tomorrow and > > return with updated results. > > Hmm, I'd rebuilt kernel with WITNESS/WITNESS_SKIPSPIN and can't reproduce > this > deadlock. Will try further. On the other hand, after boot I see several LORs: Dec 8 02:34:18 beaver kernel: lock order reversal: Dec 8 02:34:18 beaver kernel: 1st 0xfe005163b818 zfs (zfs) @ /usr/src/sys/kern/vfs_mount.c:829 Dec 8 02:34:18 beaver kernel: 2nd 0xfe005163cbd8 devfs (devfs) @ /usr/src/sys/kern/vfs_subr.c:2166 Dec 8 02:34:18 beaver kernel: KDB: stack backtrace: Dec 8 02:34:18 beaver kernel: db_trace_self_wrapper() at db_trace_self_wrapper+0x2a Dec 8 02:34:18 beaver kernel: kdb_backtrace() at kdb_backtrace+0x37 Dec 8 02:34:18 beaver kernel: _witness_debugger() at _witness_debugger+0x2c Dec 8 02:34:18 beaver kernel: witness_checkorder() at witness_checkorder+0x651 Dec 8 02:34:18 beaver kernel: __lockmgr_args() at __lockmgr_args+0xb98 Dec 8 02:34:18 beaver kernel: vop_stdlock() at vop_stdlock+0x39 Dec 8 02:34:18 beaver kernel: VOP_LOCK1_APV() at VOP_LOCK1_APV+0x46 Dec 8 02:34:18 beaver kernel: _vn_lock() at _vn_lock+0x47 Dec 8 02:34:18 beaver kernel: vget() at vget+0x56 Dec 8 02:34:18 beaver kernel: devfs_allocv() at devfs_allocv+0x13f Dec 8 02:34:18 beaver kernel: devfs_root() at devfs_root+0x4d Dec 8 02:34:18 beaver kernel: vfs_donmount() at vfs_donmount+0xdcb Dec 8 02:34:18 beaver kernel: sys_nmount() at sys_nmount+0x63 Dec 8 02:34:18 beaver kernel: amd64_syscall() at amd64_syscall+0x25a Dec 8 02:34:18 beaver kernel: Xfast_syscall() at Xfast_syscall+0xf7 Dec 8 02:34:18 beaver kernel: --- syscall (378, FreeBSD ELF64, sys_nmount), rip = 0x800ab5ecc, rsp = 0x7fffccc8, rbp = 0x801009048 --- Dec 8 02:34:29 beaver kernel: 4-i386.lab.rinet.ru Dec 8 02:34:32 beaver kernel: 6-i386.lab.rinet.ru. Dec 8 02:41:15 beaver kernel: lock order reversal: Dec 8 02:41:15 beaver kernel: 1st 0xfe004ea069f8 tmpfs (tmpfs) @ /usr/src/sys/fs/nullfs/null_vnops.c:597 Dec 8 02:41:15 beaver kernel: 2nd 0xfe019db46bd8 zfs (zfs) @ /usr/src/sys/fs/nullfs/null_vnops.c:597 Dec 8 02:41:15 beaver kernel: KDB: stack backtrace: Dec 8 02:41:15 beaver kernel: db_trace_self_wrapper() at db_trace_self_wrapper+0x2a Dec 8 02:41:15 beaver kernel: kdb_backtrace() at kdb_backtrace+0x37 Dec 8 02:41:15 beaver kernel: _witness_debugger() at _witness_debugger+0x2c Dec 8 02:41:15 beaver kernel: witness_checkorder() at witness_checkorder+0x651 Dec 8 02:41:15 beaver kernel: __lockmgr_args() at __lockmgr_args+0xb98 Dec 8 02:41:15 beaver kernel: vop_stdlock() at vop_stdlock+0x39 Dec 8 02:41:15 beaver kernel: VOP_LOCK1_APV() at VOP_LOCK1_APV+0x46 Dec 8 02:41:15 beaver kernel: null_lock() at null_lock+0xbb Dec 8 02:41:15 beaver kernel: VOP_LOCK1_APV() at VOP_LOCK1_APV+0x46 Dec 8 02:41:15 beaver kernel: _vn_lock() at _vn_lock+0x47 Dec 8 02:41:15 beaver kernel: nullfs_root() at nullfs_root+0x45 Dec 8 02:41:15 beaver kernel: vfs_donmount() at vfs_donmount+0xdcb Dec 8 02:41:15 beaver kernel: sys_nmount() at sys_nmount+0x63 Dec 8 02:41:15 beaver kernel: amd64_syscall() at amd64_syscall+0x25a Dec 8 02:41:15 beaver kernel: Xfast_syscall() at Xfast_syscall+0xf7 Dec 8 02:41:15 beaver kernel: --- syscall (378, FreeBSD ELF64, sys_nmount), rip = 0x8008a1ecc, rsp = 0x7fffceb8, rbp = 0x7fffcf30 --- Dec 8 02:41:16 beaver kernel: lock order reversal: Dec 8 02:41:16 beaver kernel: 1st 0xfe0171868638 tmpfs (tmpfs) @ /usr/src/sys/fs/nullfs/null_vnops.c:597 Dec 8 02:41:16 beaver kernel: 2nd 0xfe004ea0ebd8 devfs (devfs) @ /usr/src/sys/kern/vfs_subr.c:2166 Dec 8 02:41:16 beaver kernel: KDB: stack backtrace: Dec 8 02:41:16 beaver kernel: db_trace_self_wrapper() at db_trace_self_wrapper+0x2a Dec 8 02:41:16 beaver kernel: kdb_backtrace() at kdb_backtrace+0x37 Dec 8 02:41:16 beaver kernel: _witness_debugger() at _witness_debugger+0x2c Dec 8 02:41:16 beaver kernel: witness_checkorder() at witness_checkorder+0x651 Dec 8 02:41:16 beaver kernel: __lockmgr_args() at __lockmgr_args+0xb98 Dec 8 02:41:16 beaver kernel: vop_stdlock() at vop_stdlock+0x39 Dec 8 02:41:16 beaver kernel: VOP_LOCK1_APV() at VOP_LOCK1_APV+0x46 Dec 8 02:41:16 beaver kernel: _vn_lock() at _vn_lock+0x47 Dec 8 02:41:16 beaver kernel: vget() at vget+0x56 Dec 8 02:41:16 beaver kernel: devfs_allocv() at devfs_allocv+0x13f Dec 8 02:41:16 beaver k
ahci hangs on Supermicro MicroCloud second channel
Dear colleagues, I've start testing SuperMicro MicroCloud[1] to have high-density routers cluster, and experiencing strange effects with disk subsystem: - on stable/8, it does detect AHCI controller, but detects disks as non-ahci ad* - on stable/9, disks are shown as ada*, but disk on second channel has constant read/write hangs, showing 100% load on few hundreds kBps in gstat. disk controller is Intel C204 PCH: ahci0: port 0xf050-0xf057,0xf040-0xf043,0xf030-0xf037,0xf020-0xf023,0xf000-0xf01f mem 0xfa901000-0xfa9017ff irq 19 at device 31.2 on pci0 ahci0: attempting to allocate 1 MSI vectors (1 supported) msi: routing MSI IRQ 284 to local APIC 0 vector 81 ahci0: using IRQ 284 for MSI ahci0: AHCI v1.30 with 6 6Gbps ports, Port Multiplier not supported ahci0: Caps: 64bit NCQ SNTF ALP AL CLO 6Gbps PMD SSC PSC 32cmd EM 6ports ahci0: Caps2: APST ahci0: EM Caps: ALHD XMT SMB LED ahcich0: at channel 0 on ahci0 ahcich0: Caps: ahcich1: at channel 1 on ahci0 ahcich1: Caps: pass0 at ahcich0 bus 0 scbus0 target 0 lun 0 pass0: ATA-8 SATA 3.x device pass0: Serial Number WD-WCAYUFH26175 pass0: 600.000MB/s transfers (SATA 3.x, UDMA6, PIO 8192bytes) pass0: Command Queueing enabled pass1 at ahcich1 bus 0 scbus1 target 0 lun 0 pass1: ATA-8 SATA 3.x device pass1: Serial Number WD-WCAYUFH32290 pass1: 600.000MB/s transfers (SATA 3.x, UDMA6, PIO 8192bytes) pass1: Command Queueing enabled ada0 at ahcich0 bus 0 scbus0 target 0 lun 0 ada0: ATA-8 SATA 3.x device ada0: Serial Number WD-WCAYUFH26175 ada0: 600.000MB/s transfers (SATA 3.x, UDMA6, PIO 8192bytes) ada0: Command Queueing enabled ada0: 476940MB (976773168 512 byte sectors: 16H 63S/T 16383C) ada0: Previously was known as ad4 ada1 at ahcich1 bus 0 scbus1 target 0 lun 0 GEOM: new disk ada0 GEOM: new disk ada1 ada1: ATA-8 SATA 3.x device ada1: Serial Number WD-WCAYUFH32290 ada1: 600.000MB/s transfers (SATA 3.x, UDMA6, PIO 8192bytes) ada1: Command Queueing enabled ada1: 476940MB (976773168 512 byte sectors: 16H 63S/T 16383C) ada1: Previously was known as ad6 Any hints? [1] http://www.supermicro.nl/products/system/3U/5037/SYS-5037MC-H8TRF.cfm -- Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] [ FreeBSD committer: ma...@freebsd.org ] *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- ma...@rinet.ru *** ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: ahci hangs on Supermicro MicroCloud second channel
On Sun, 18 Mar 2012, G?t Andr?s wrote: > Hi, > > Did you check whether there's newer firmware for the microcloud mainboards? > Does the integrated ctrls are in AHCI mode in the BIOS? Yes and yes, surely. > You may also ask Supermicro if it turns out that it's not a FreeBSD problem, > but be prepared that they'll ask for enterprise drives first. I can check with WD REs (have some spares for more disk-oriented servers, also SuperMicro), but let it be the latter phase. What puzzles me a bit is that it is not the first 1155 SuperMicro platform we use on 5017C-MTF it seems the same controller: ahci0: port 0xf070-0xf077,0xf060-0xf063,0xf050-0xf057,0xf040-0xf043,0xf000-0xf01f mem 0xfb121000-0xfb1217ff irq 19 at device 31.2 on pci0 ahci0: Reserved 0x800 bytes for rid 0x24 type 3 at 0xfb121000 ahci0: attempting to allocate 1 MSI vectors (1 supported) msi: routing MSI IRQ 266 to local APIC 0 vector 59 ahci0: using IRQ 266 for MSI ahci0: [MPSAFE] ahci0: [ITHREAD] ahci0: AHCI v1.30 with 6 6Gbps ports, Port Multiplier not supported and ahci with the same pair of WD Blues works flawlessly > > Regards, > Andras > > > On Sun, 18 Mar 2012 20:10:34 +0400 (MSK), Dmitry Morozovsky wrote: > > Dear colleagues, > > > > I've start testing SuperMicro MicroCloud[1] to have high-density routers > > cluster, and experiencing strange effects with disk subsystem: > > > > - on stable/8, it does detect AHCI controller, but detects disks as non-ahci > > ad* > > - on stable/9, disks are shown as ada*, but disk on second channel > > has constant > > read/write hangs, showing 100% load on few hundreds kBps in gstat. > > > > disk controller is Intel C204 PCH: > > > > ahci0: port > > 0xf050-0xf057,0xf040-0xf043,0xf030-0xf037,0xf020-0xf023,0xf000-0xf01f mem > > 0xfa901000-0xfa9017ff irq 19 at device 31.2 on pci0 > > ahci0: attempting to allocate 1 MSI vectors (1 supported) > > msi: routing MSI IRQ 284 to local APIC 0 vector 81 > > ahci0: using IRQ 284 for MSI > > ahci0: AHCI v1.30 with 6 6Gbps ports, Port Multiplier not supported > > ahci0: Caps: 64bit NCQ SNTF ALP AL CLO 6Gbps PMD SSC PSC 32cmd EM 6ports > > ahci0: Caps2: APST > > ahci0: EM Caps: ALHD XMT SMB LED > > ahcich0: at channel 0 on ahci0 > > ahcich0: Caps: > > ahcich1: at channel 1 on ahci0 > > ahcich1: Caps: > > > > pass0 at ahcich0 bus 0 scbus0 target 0 lun 0 > > pass0: ATA-8 SATA 3.x device > > pass0: Serial Number WD-WCAYUFH26175 > > pass0: 600.000MB/s transfers (SATA 3.x, UDMA6, PIO 8192bytes) > > pass0: Command Queueing enabled > > pass1 at ahcich1 bus 0 scbus1 target 0 lun 0 > > pass1: ATA-8 SATA 3.x device > > pass1: Serial Number WD-WCAYUFH32290 > > pass1: 600.000MB/s transfers (SATA 3.x, UDMA6, PIO 8192bytes) > > pass1: Command Queueing enabled > > ada0 at ahcich0 bus 0 scbus0 target 0 lun 0 > > ada0: ATA-8 SATA 3.x device > > ada0: Serial Number WD-WCAYUFH26175 > > ada0: 600.000MB/s transfers (SATA 3.x, UDMA6, PIO 8192bytes) > > ada0: Command Queueing enabled > > ada0: 476940MB (976773168 512 byte sectors: 16H 63S/T 16383C) > > ada0: Previously was known as ad4 > > ada1 at ahcich1 bus 0 scbus1 target 0 lun 0 > > GEOM: new disk ada0 > > GEOM: new disk ada1 > > ada1: ATA-8 SATA 3.x device > > ada1: Serial Number WD-WCAYUFH32290 > > ada1: 600.000MB/s transfers (SATA 3.x, UDMA6, PIO 8192bytes) > > ada1: Command Queueing enabled > > ada1: 476940MB (976773168 512 byte sectors: 16H 63S/T 16383C) > > ada1: Previously was known as ad6 > > > > Any hints? > > > > > > [1] http://www.supermicro.nl/products/system/3U/5037/SYS-5037MC-H8TRF.cfm > > ___ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org" > -- Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] [ FreeBSD committer: ma...@freebsd.org ] *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- ma...@rinet.ru *** ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: ahci hangs on Supermicro MicroCloud second channel
Steven, On Sun, 18 Mar 2012, Steven Hartland wrote: [snip] > We have quite a few of these running 8.2-RELEASE-p6 on AHCI with no > problems (kernel compiled with:- device ahci) > > ahci0: port > 0xf050-0xf057,0xf040-0xf043,0xf030-0xf037,0xf020-0xf023,0xf000-0xf01f mem > 0xfbc01000-0xfbc017ff irq 19 at device 31.2 on pci0 > ahci0: [ITHREAD] > ahci0: AHCI v1.30 with 6 6Gbps ports, Port Multiplier not supported > ahcich0: at channel 0 on ahci0 > ahcich0: [ITHREAD] > ahcich1: at channel 1 on ahci0 > ahcich1: [ITHREAD] > > ada0 at ahcich0 bus 0 scbus0 target 0 lun 0 > ada0: ATA-8 SATA 2.x device > ada0: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) > ada0: Command Queueing enabled > ada0: 953869MB (1953525168 512 byte sectors: 16H 63S/T 16383C) > ada1 at ahcich1 bus 0 scbus1 target 0 lun 0 > ada1: ATA-8 SATA 3.x device > ada1: 600.000MB/s transfers (SATA 3.x, UDMA6, PIO 8192bytes) > ada1: Command Queueing enabled > ada1: 57241MB (117231408 512 byte sectors: 16H 63S/T 16383C) > > Given this might be worth seeing if 8.2 on AHCI fixes the > hangs and hence its a regression in 9. If your running > generic you should be able to just add the following to > /boot/loader.conf > ahci_load="YES" Yes, I did it, but all I have ... wait a bit... Yes, I missed ahci.ko module on my PXE server in amd64/8 tree :-/ [kernel reinstall] Well, ahci problem solved, but I still have much worse performance (and different on ada0 and ada1!): ada0, MC50-60 MBps ada1, MC13-25 MBps ada*, 5017 130+ MBps Could you please post SATA/AHCI BIOS settings from your machines? Thanks a lot! -- Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] [ FreeBSD committer: ma...@freebsd.org ] *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- ma...@rinet.ru *** ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: ahci hangs on Supermicro MicroCloud second channel
On Sun, 18 Mar 2012, Steven Hartland wrote: > > different on ada0 and ada1!): > > ada0, MC 50-60 MBps ada1, MC 13-25 MBps > > ada*, 5017 130+ MBps > > > > Could you please post SATA/AHCI BIOS settings from your machines? Thanks a > > lot! > > Just AHCI configured as far as I remember. Microcloud has AFAIR additional settings for delaying disk spin and enablink/disabling hotswap, but mangling these options does not change anything for me > What you mean by MC vs 5017? platform name: MicroCloud vs 5017C-MTF, both based on the same chipset > How are you measuring disk speed? the simplest: dd if=/dev/ada0 of=/dev/null bs=1m count=16k (linear read 16g at the beginning of disk) > What value do you have for sysctl vfs.read_max? default for both cases, 8 -- Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] [ FreeBSD committer: ma...@freebsd.org ] -------- *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- ma...@rinet.ru *** ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: ahci hangs on Supermicro MicroCloud second channel
On Sun, 18 Mar 2012, Steven Hartland wrote: [snip] > Not sure its been released yet but we where running a pre-release BIOS which > added the ability to disabled C1E, which caused us CPU performance issue in > are particular environment. This sounds interesting. Could you please share some links? Our MicroCloud blades have BIOS 1.0a, which is the latest mentioned at SuperMicro site. Thanks! -- Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] [ FreeBSD committer: ma...@freebsd.org ] *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- ma...@rinet.ru *** ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: ahci hangs on Supermicro MicroCloud second channel
On Mon, 19 Mar 2012, Steven Hartland wrote: > > > Not sure its been released yet but we where running a pre-release BIOS > > > which > > > added the ability to disabled C1E, which caused us CPU performance issue > > > in > > > are particular environment. > > > > This sounds interesting. Could you please share some links? Our MicroCloud > > blades have BIOS 1.0a, which is the latest mentioned at SuperMicro site. > > Its 1.0b, I'm sure if you ask Supermicro for it they will provide otherwise > I'll fire it to you on private email. Quick update: I have received 1.0b from Mar 19, flashed it, but nothing changes regarding disk subsystem; moreover, now kernel is constantly whining about acpi_tz0. Will investigate further. -- Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] [ FreeBSD committer: ma...@freebsd.org ] ---- *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- ma...@rinet.ru *** ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: ahci hangs on Supermicro MicroCloud second channel
On Wed, 21 Mar 2012, Steven Hartland wrote: > > I have received 1.0b from Mar 19, flashed it, but nothing changes regarding > > disk subsystem; moreover, now kernel is constantly whining about acpi_tz0. > > > > Will investigate further. > > Which version of FreeBSD is this on Dmitry? Just checked our machines here > and not seeing anything in /var/log/messages about this, so curious. I'm now testing two blades, one with releng/8, and second with releng/9. Same effect. -- Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] [ FreeBSD committer: ma...@freebsd.org ] -------- *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- ma...@rinet.ru *** ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: ahci hangs on Supermicro MicroCloud second channel
On Thu, 22 Mar 2012, Dmitry Morozovsky wrote: > > > I have received 1.0b from Mar 19, flashed it, but nothing changes > > > regarding > > > disk subsystem; moreover, now kernel is constantly whining about acpi_tz0. > > > > > > Will investigate further. > > > > Which version of FreeBSD is this on Dmitry? Just checked our machines here > > and not seeing anything in /var/log/messages about this, so curious. > > I'm now testing two blades, one with releng/8, and second with releng/9. Same > effect. For the archives: yes, it seems very strange glitch with these blades and WD Caviar Blue AAKX: quick test with Hitachi 3T revieals expected 130+ Mbps throughput. What puzzles me most is that the very same disks work flawlessly on the very same chipset, but different SuperMicro platform. I just ordered another batch of small disks, will test with them. -- Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] [ FreeBSD committer: ma...@freebsd.org ] -------- *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- ma...@rinet.ru *** ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: sys/modules/geom/geom_part/geom_part_apm compilation error
On Sun, 23 May 2010, Ronald van der Pol wrote: RvdP> I want to try the ix(4) 10GE driver on -STABLE. I am compiling -STABLE RvdP> on a test server. I cvsup'd -STABLE in a clean /usr/src. Compiling RvdP> world went fine. Kernel stops with this error: RvdP> RvdP> /usr/src/sys/modules/geom/geom_part/geom_part_apm/../../../../geom/part/g_part_apm.c:131: error: 'G_PART_ALIAS_APPLE_BOOT' undeclared (first use in this function) RvdP> /usr/src/sys/modules/geom/geom_part/geom_part_apm/../../../../geom/part/g_part_apm.c:131: error: (Each undeclared identifier is reported only once RvdP> /usr/src/sys/modules/geom/geom_part/geom_part_apm/../../../../geom/part/g_part_apm.c:131: error: for each function it appears in.) RvdP> /usr/src/sys/modules/geom/geom_part/geom_part_apm/../../../../geom/part/g_part_apm.c:141: error: 'G_PART_ALIAS_APPLE_UFS' undeclared (first use in this function) RvdP> /usr/src/sys/modules/geom/geom_part/geom_part_apm/../../../../geom/part/g_part_apm.c: In function 'g_part_apm_type': RvdP> /usr/src/sys/modules/geom/geom_part/geom_part_apm/../../../../geom/part/g_part_apm.c:453: error: 'G_PART_ALIAS_APPLE_BOOT' undeclared (first use in this function) RvdP> /usr/src/sys/modules/geom/geom_part/geom_part_apm/../../../../geom/part/g_part_apm.c:457: error: 'G_PART_ALIAS_APPLE_UFS' undeclared (first use in this function) RvdP> *** Error code 1 yep, it's broken now. Wait for a few hours, or try to integrate SVN change 200534 (to /sys/geom/part/*). -- Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] [ FreeBSD committer: ma...@freebsd.org ] *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- ma...@rinet.ru *** ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: sys/modules/geom/geom_part/geom_part_apm compilation error
On Sun, 23 May 2010, Dmitry Morozovsky wrote: DM> RvdP> I want to try the ix(4) 10GE driver on -STABLE. I am compiling -STABLE DM> RvdP> on a test server. I cvsup'd -STABLE in a clean /usr/src. Compiling DM> RvdP> world went fine. Kernel stops with this error: DM> RvdP> DM> RvdP> /usr/src/sys/modules/geom/geom_part/geom_part_apm/../../../../geom/part/g_part_apm.c:131: error: 'G_PART_ALIAS_APPLE_BOOT' undeclared (first use in this function) DM> RvdP> /usr/src/sys/modules/geom/geom_part/geom_part_apm/../../../../geom/part/g_part_apm.c:131: error: (Each undeclared identifier is reported only once DM> RvdP> /usr/src/sys/modules/geom/geom_part/geom_part_apm/../../../../geom/part/g_part_apm.c:131: error: for each function it appears in.) DM> RvdP> /usr/src/sys/modules/geom/geom_part/geom_part_apm/../../../../geom/part/g_part_apm.c:141: error: 'G_PART_ALIAS_APPLE_UFS' undeclared (first use in this function) DM> RvdP> /usr/src/sys/modules/geom/geom_part/geom_part_apm/../../../../geom/part/g_part_apm.c: In function 'g_part_apm_type': DM> RvdP> /usr/src/sys/modules/geom/geom_part/geom_part_apm/../../../../geom/part/g_part_apm.c:453: error: 'G_PART_ALIAS_APPLE_BOOT' undeclared (first use in this function) DM> RvdP> /usr/src/sys/modules/geom/geom_part/geom_part_apm/../../../../geom/part/g_part_apm.c:457: error: 'G_PART_ALIAS_APPLE_UFS' undeclared (first use in this function) DM> RvdP> *** Error code 1 DM> DM> yep, it's broken now. DM> DM> Wait for a few hours, or try to integrate SVN change 200534 (to DM> /sys/geom/part/*). Of course, you can also strip down module list to only needed with something like MODULES_OVERRIDE="ipfw dummynet" (see output of kldstat) in your /etc/make.conf -- Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] [ FreeBSD committer: ma...@freebsd.org ] *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- ma...@rinet.ru *** ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: sys/modules/geom/geom_part/geom_part_apm compilation error
On Sun, 23 May 2010, Ronald van der Pol wrote: RvdP> On Sun, May 23, 2010 at 17:58:51 +0400, Dmitry Morozovsky wrote: RvdP> RvdP> > Wait for a few hours, or try to integrate SVN change 200534 (to RvdP> > /sys/geom/part/*). RvdP> RvdP> I waited for the new commit. The kernel is now building fine. RvdP> Thanks! RvdP> RvdP> I ran into a problem when installing the kernel. The root filesystem RvdP> ran out of space. I used the defaults when installing FreeBSD. RvdP> Apparently, the default for root is way too small. That should RvdP> not happen. I know I thought 500 MB is not much, but hey, it's RvdP> the suggested default. I think somebody should look into that RvdP> before the 8.1 release. Workarounds: - define MODULES_OVERRIDE as I said earlier - define INSTALL_NODEBUG which prevents .symbols files from polluting your root RvdP> And I now did a "ifconfig ix0 mtu 9000" and the system went dead. RvdP> It's pinging on another interface, but ssh to that interface does RvdP> not work. I have to look at the console tomorrow :-( Not good either :( -- Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] [ FreeBSD committer: ma...@freebsd.org ] -------- *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- ma...@rinet.ru *** ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
same addresses on different interfaces
Dear colleagues, is it OK that no warnings are given when one set the very same address on different interfaces? Example (tested on stable/7 and stable/8): Script started on Fri Jun 11 13:44:08 2010 hamster# ifconfig vlan8 create vlan 8 vlandev em0 hamster# ifconfig vlan8 10.5.5.9/30 hamster# netstat -rn | grep '10\.5' 10.5.5.8/30link#3 U 00 vlan8 10.5.5.9 link#3 UHS 00lo0 hamster# ifconfig vlan9 create vlan 9 vlandev em0 hamster# ifconfig vlan9 10.5.5.9/30 hamster# netstat -rn | grep '10\.5' 10.5.5.8/30link#3 U 00 vlan8 10.5.5.9 link#3 UHS 10lo0 hamster# exit Script done on Fri Jun 11 13:46:24 2010 Thanks. -- Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] [ FreeBSD committer: ma...@freebsd.org ] ---- *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- ma...@rinet.ru *** ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: same addresses on different interfaces
On Fri, 11 Jun 2010, Dmitry Morozovsky wrote: DM> is it OK that no warnings are given when one set the very same address on DM> different interfaces? Example (tested on stable/7 and stable/8): DM> DM> Script started on Fri Jun 11 13:44:08 2010 DM> DM> hamster# ifconfig vlan8 create vlan 8 vlandev em0 DM> hamster# ifconfig vlan8 10.5.5.9/30 DM> hamster# netstat -rn | grep '10\.5' DM> 10.5.5.8/30link#3 U 00 vlan8 DM> 10.5.5.9 link#3 UHS 00lo0 DM> hamster# ifconfig vlan9 create vlan 9 vlandev em0 DM> hamster# ifconfig vlan9 10.5.5.9/30 DM> hamster# netstat -rn | grep '10\.5' DM> 10.5.5.8/30link#3 U 00 vlan8 DM> 10.5.5.9 link#3 UHS 10lo0 DM> hamster# exit DM> DM> Script done on Fri Jun 11 13:46:24 2010 Well, one of my colleagues pointed me to the fact that inexclusive routes are now possible (which possibly leads to the question why setting the address which network route is learnt by external means, such as from routing daemon, is still prohibited). Bu then, another question: when someone set a situation like above, and then destroys primary route (via shutting the interface down, deleting address, etc) - the second one remains its ad ress, but routing entry will be deleted. Is it really intended? -- Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] [ FreeBSD committer: ma...@freebsd.org ] -------- *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- ma...@rinet.ru *** ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Using GTP and glabel for ZFS arrays
On Fri, 23 Jul 2010, John Hawkes-Reed wrote: JH> Since I still have the medium-sized ZFS array on the bench, testing this GPT JH> setup seemed like a good idea. JH> JH> The hardware's a Supermicro X8DTL-iF m/b + 12Gb memory, 2x 5502 Xeons, 3x JH> Supermicro USASLP-L8I 3G SAS controllers and 24x Hitachi 2Tb drives. [snip] JH> For an apples/oranges comparison, here's the output from the other box we JH> built. The hardware's more or less the same - the drive controller's an JH> Areca-1280, but the OS was Solaris 10.latest: JH> JH>Sequential Output--- ---Sequential Input-- --Random-- JH>-Per Char- --Block--- -Rewrite-- -Per Char- --Block--- --Seeks--- JH> JH> GB M/sec %CPU M/sec %CPU M/sec %CPU M/sec %CPU M/sec %CPU /sec %CPU JH> 5 116.8 75.0 524.7 65.4 156.3 20.3 161.6 99.2 2924.0 100.0 19 300.0 . ~~ Frakking Cylons! You have quite a beast! ;-) -- Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] [ FreeBSD committer: ma...@freebsd.org ] -------- *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- ma...@rinet.ru *** ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: gpart -b 34 versus gpart -b 1024
On Sun, 25 Jul 2010, Adam Vande More wrote: AVM> > AVM> > shouldn't it start at 2049? Starting at 2048 means it starts at 2048th AVM> > logical block which is 512 bytes off from physical block, doesn't it? AVM> > <http://www.asciiribbon.org> AVM> > AVM> AVM> blocks start at 0 Well, to be exact, LBA starts at 0, while sector numbers (in CHS address method) at 1 (which always suprized me ;) -- Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] [ FreeBSD committer: ma...@freebsd.org ] -------- *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- ma...@rinet.ru *** ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
csup in repomirror mode dumps core @ stable/8
Dear colleagues, some 2 days ago my repo mirror (stable/8...@amd64) starts dumping core on copying repo: ... SetAttrs CVSROOT-src/Emptydir Edit CVSROOT-src/access,v Segmentation fault (core dumped) deleting files from sup/cvsroot-all/ did not help unfortunately, quick usual `make -DDEBUG_FLAGS=-g' in /usr/src/usr.bin/csup does not work, and I did not dig into this deeply yet, so trace are without parameters: (gdb) bt #0 0x00410676 in rcsdelta_addlog () #1 0x00412b15 in rcsparse_run () #2 0x00412453 in rcsfile_frompath () #3 0x00417c45 in updater_rcsedit () #4 0x00419a59 in updater_batch () #5 0x0041a1d1 in updater () #6 0x004158c4 in thread_start () #7 0x000800a1c511 in pthread_getprio () from /lib/libthr.so.3 #8 0x in ?? () Cannot access memory at address 0x7f1fa000 Any hints? -- Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] [ FreeBSD committer: ma...@freebsd.org ] *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- ma...@rinet.ru *** ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: csup in repomirror mode dumps core @ stable/8
On Thu, 2 Sep 2010, Kostik Belousov wrote: KB> On Thu, Sep 02, 2010 at 03:59:07AM +0400, Dmitry Morozovsky wrote: KB> > Dear colleagues, KB> > KB> > some 2 days ago my repo mirror (stable/8...@amd64) starts dumping core on copying KB> > repo: KB> > KB> > ... KB> > SetAttrs CVSROOT-src/Emptydir KB> > Edit CVSROOT-src/access,v KB> > Segmentation fault (core dumped) KB> > KB> > deleting files from sup/cvsroot-all/ did not help KB> > KB> > unfortunately, quick usual `make -DDEBUG_FLAGS=-g' in /usr/src/usr.bin/csup KB> > does not work, and I did not dig into this deeply yet, so trace are without KB> > parameters: KB> I think it should be DEBUG_FLAGS=-g and not -D"...". Yes, surely you're right. BTW, I can confirm moving away access,v file helps avoiding core. -- Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] [ FreeBSD committer: ma...@freebsd.org ] *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- ma...@rinet.ru *** ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
kern/150859: tmpfs on stable/8-amd64 panic
Dear colleagues, I've finally managed to get good crashdump with tmpfs stressing under ports tinderbox. I've filed kern/150859 Any other info I missed to track the issue further? Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] [ FreeBSD committer: ma...@freebsd.org ] ---- *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- ma...@rinet.ru *** ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: kern/150859: tmpfs on stable/8-amd64 panic
On Wed, 22 Sep 2010, Andriy Gapon wrote:
AG> on 22/09/2010 17:42 Dmitry Morozovsky said the following:
AG> > Dear colleagues,
AG> >
AG> > I've finally managed to get good crashdump with tmpfs stressing under
ports
AG> > tinderbox.
AG> >
AG> > I've filed kern/150859
AG>
AG> Please, in frame 10 print *node and *vp.
AG> Thanks!
(kgdb) up 10
#10 0x80c24f5e in tmpfs_alloc_vp (mp=0xff000a23,
node=0xff001f8fa7e0, lkflag=525312, vpp=0xff81ddf542f0)
at /usr/src/sys/modules/tmpfs/../../fs/tmpfs/tmpfs_subr.c:383
383 panic("tmpfs_alloc_vp: type %p %d", node,
(int)node->tn_type);
(kgdb) p *node
$1 = {tn_entries = {le_next = 0xff006357fd20, le_prev =
0xff01457602a0}, tn_type = VNON, tn_id = 19, tn_status = 14, tn_size = 0,
tn_uid = 0, tn_gid = 0, tn_mode = 1023,
tn_flags = 0, tn_links = 0, tn_atime = {tv_sec = 1285154193, tv_nsec = 0},
tn_mtime = {tv_sec = 1285154193, tv_nsec = 0}, tn_ctime = {tv_sec = 1285154193,
tv_nsec = 0},
tn_birthtime = {tv_sec = 1284235757, tv_nsec = 0}, tn_gen = 3591316855,
tn_vnode = 0x0, tn_interlock = {lock_object = {lo_name = 0x80c26166
"tmpfs node interlock",
lo_flags = 16973824, lo_data = 0, lo_witness = 0x0}, mtx_lock = 4},
tn_vpstate = 1, tn_spec = {tn_rdev = 894943680, tn_dir = {tn_parent =
0xff013557c1c0, tn_dirhead = {
tqh_first = 0x0, tqh_last = 0xff001f8fa8a0}, tn_readdir_lastn = 0,
tn_readdir_lastp = 0x0}, tn_link = 0xff013557c1c0 "", tn_reg = {tn_aobj =
0xff013557c1c0,
tn_aobj_pages = 0}, tn_fifo = {tn_fo_read = 0xff013557c1c0,
tn_fo_write = 0}}}
(kgdb) p *vp
$2 = {v_type = VNON, v_tag = 0x80c261b4 "tmpfs", v_op =
0x80c26260, v_data = 0xff001f8fa7e0, v_mount = 0x0, v_nmntvnodes =
{tqe_next = 0x0, tqe_prev = 0x0},
v_un = {vu_mount = 0x0, vu_socket = 0x0, vu_cdev = 0x0, vu_fifoinfo = 0x0,
vu_yield = 0}, v_hashlist = {le_next = 0x0, le_prev = 0x0}, v_hash = 0,
v_cache_src = {
lh_first = 0x0}, v_cache_dst = {tqh_first = 0x0, tqh_last =
0xff0013258998}, v_cache_dd = 0x0, v_cstart = 0, v_lasta = 0, v_lastw = 0,
v_clen = 0, v_lock = {
lock_object = {lo_name = 0x80c261b4 "tmpfs", lo_flags = 91422728,
lo_data = 0, lo_witness = 0x0}, lk_lock = 18446742976956241856, lk_timo = 51,
lk_pri = 80},
v_interlock = {lock_object = {lo_name = 0x80566220 "vnode interlock",
lo_flags = 16973824, lo_data = 0, lo_witness = 0x0}, mtx_lock = 4},
v_vnlock = 0xff00132589d0, v_holdcnt = 1, v_usecount = 1, 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 = 0x80566230 "bufobj interlock", lo_flags
= 16973824, lo_data = 0, lo_witness = 0x0}, mtx_lock = 4}, bo_clean = {bv_hd =
{tqh_first = 0x0,
tqh_last = 0xff0013258a70}, bv_root = 0x0, bv_cnt = 0}, bo_dirty =
{bv_hd = {tqh_first = 0x0, tqh_last = 0xff0013258a90}, bv_root = 0x0,
bv_cnt = 0},
bo_numoutput = 0, bo_flag = 0, bo_ops = 0x806d1c40, bo_bsize =
4096, bo_object = 0x0, bo_synclist = {le_next = 0x0, le_prev = 0x0}, bo_private
= 0xff0013258938,
__bo_vnode = 0xff0013258938}, v_pollinfo = 0x0, v_label = 0x0, v_lockf
= 0x0}
Actual panic message:
panic: tmpfs_alloc_vp: type 0xff001f8fa7e0 0
cpuid = 2
KDB: enter: panic
--
Sincerely,
D.Marck [DM5020, MCK-RIPE, DM3-RIPN]
---
*** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- ma...@freebsd.org ***
---
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
puc in GENERIC
Dear colleagues, in time of preparation for upcoming twin releases: what is preventing us from including puc driver in GENERIC? Provided more and more current non-server motherboards come without onboard com1, there is no chance for such a board to activate comconsole without puc in kernel (module loading in loader.conf is too late); having puc compiled in mitigates the issue for all cases I was faced to. Your thoughts? -- Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] [ FreeBSD committer: ma...@freebsd.org ] *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- ma...@rinet.ru *** ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Very large kernel
On Fri, 15 Aug 2008, [EMAIL PROTECTED] wrote: > > Alex de Kruijff wrote: > > > I noticed that the kernel directory was very large compaired to 6.1. Is > > > this for debugging and can I safely remove the symbols files I want to > > > save some space? > > > > Yes but if you encounter a panic and need to submit a bug report then you > > will need at least the kernel.debug and whatever modules you are using. > > Two questions for this ... > > a. can I move these to a larger partition temporarily, and if I have a crash, > move them back to do debugging? > > b. is there some setting I can use in make.conf to have it auto-install the > symbols files to a seperate directory on 'installkernel'? If you do not clean your /usr/obj regularly, you can simply use make installkernel KERNCONF=MYOWN INSTALL_NODEBUG= and later use .symbols files from /usr/obj/.../sys/MYOWN/* Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] [ FreeBSD committer: [EMAIL PROTECTED] ] ---- *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- [EMAIL PROTECTED] *** ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
RELENG_7/amd64: booting from gpt failed.
Dear colleagues, I'm trying to set up new machine with RAID array slightly larger than 2T, so I'm forced to use gpt. I did successfully gpt create gpt boot gpt add newfs tar base system gpt show output looks like: startsize index contents 0 1 PMBR 1 1 Pri GPT header 2 32 Pri GPT table 34 128 1 GPT part - FreeBSD boot 162 1048576 2 GPT part - FreeBSD UFS/UFS2 104873833554432 3 GPT part - FreeBSD swap 34603170 4359862077 4 GPT part - FreeBSD ZFS 4394465247 32 Sec GPT table 4394465279 1 Sec GPT header and I hope it boots from da0p2, but it fails: /boot.config: -Dh -S115200 FreeBSD/i386 boot Default: 0:ad(0p2)/boot/loader boot: Consoles: internal video/keyboard serial port BIOS drive C: is disk0 BIOS 628kB/3405248kB available memory FreeBSD/i386 bootstrap loader, Revision 1.1 ([EMAIL PROTECTED], Wed Feb 20 17:29:26 MSK 2008) can't load 'kernel' Type '?' for a list of commands, 'help' for more detailed help. OK ls bad path '' OK show loaddev disk0s2`: OK show currdev disk0s2`: Quick googling does not help much. Any hints? Thanks in advance. Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] [ FreeBSD committer: [EMAIL PROTECTED] ] -------- *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- [EMAIL PROTECTED] *** ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: RELENG_7/amd64: booting from gpt failed.
On Tue, 2 Sep 2008, Dmitry Morozovsky wrote: [snip] DM> and I hope it boots from da0p2, but it fails: Pilot error; rebuilding fresh RELENG_7 from scratch and reinstall fixed the issue; now I'm almost happy with new 4-core builder/tinderbox with ZFS over gpt. ;) Sorry for the noise. Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] [ FreeBSD committer: [EMAIL PROTECTED] ] ---- *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- [EMAIL PROTECTED] *** ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
mysterious uname non-updates
Dear colleagues, today, updating one of my machines, I got the following mysterious results after reboot: [EMAIL PROTECTED]:~# sysctl -a | grep RELE kern.osrelease: 6.3-RELEASE kern.version: FreeBSD 6.3-RELEASE #4: Thu Jan 17 15:28:57 MSK 2008 [EMAIL PROTECTED]:~# strings /boot/kernel/kernel | grep RELE AE_RELEASE_DEADLOCK 6.3-RELEASE-p4 FreeBSD 6.3-RELEASE-p4 #6: Sun Sep 7 23:13:45 MSD 2008 @(#)FreeBSD 6.3-RELEASE-p4 #6: Sun Sep 7 23:13:45 MSD 2008 [EMAIL PROTECTED]:~# env | grep -i uname [EMAIL PROTECTED]:~# WTF? Why my kernel reports that it is previous version (actually it is already deleted, so I'm double puzzled) Any clues? Thanks! Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] [ FreeBSD committer: [EMAIL PROTECTED] ] *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- [EMAIL PROTECTED] *** ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: mysterious uname non-updates
On Mon, 8 Sep 2008, Oliver Fromme wrote: OF> > today, updating one of my machines, I got the following mysterious results OF> > after reboot: OF> > OF> > [EMAIL PROTECTED]:~# sysctl -a | grep RELE OF> > kern.osrelease: 6.3-RELEASE OF> > kern.version: FreeBSD 6.3-RELEASE #4: Thu Jan 17 15:28:57 MSK 2008 OF> > [EMAIL PROTECTED]:~# strings /boot/kernel/kernel | grep RELE OF> > AE_RELEASE_DEADLOCK OF> > 6.3-RELEASE-p4 OF> > FreeBSD 6.3-RELEASE-p4 #6: Sun Sep 7 23:13:45 MSD 2008 OF> > @(#)FreeBSD 6.3-RELEASE-p4 #6: Sun Sep 7 23:13:45 MSD 2008 OF> > [EMAIL PROTECTED]:~# env | grep -i uname OF> > [EMAIL PROTECTED]:~# OF> > OF> > WTF? Why my kernel reports that it is previous version (actually it is already OF> > deleted, so I'm double puzzled) OF> OF> What does "sysctl kern.bootfile" say? OF> And are you sure that you rebooted the right machine? ;-) sysctl kern.bootfile said correct /boot/kernel/kernel And it was the right machine, but... in a bit "interesting" configuration: there are two pairs of mirrored disks: ad4/ad6 with gmirror, and ad8/ad10 from previous installation, from which I did migrate to the first pair. All file systems are refered as /dev/mirror/* Strange and mysterious thing was sourced by ad8 somehow activated to be *BIOS BOOT DISK* - so boot blocks, loader *and kernel* was loaded from there, but root mounted from correct /dev/mirror/m0a. Removing old pair of disks returned situation to controllable ;-) Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] [ FreeBSD committer: [EMAIL PROTECTED] ] *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- [EMAIL PROTECTED] *** ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Supermicro PDSMI failed to boot on fresh RELENG_7/amd64
Colleagues, 3 of 4 times this machine failed to boot, panicing somewhere in late kernel initialization phase (before /sbin/init is executed) I have serial console and KDB enabled, so can do experiments. Last two crashes: Fatal trap 12: page fault while in kernel mode fault virtual address = 0x8 fault code = supervisor read data, page not present instruction pointer = 0x8:0x8026978a stack pointer = 0x10:0x80611810 frame pointer = 0x10:0x80611830 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags= interrupt enabled, resume, IOPL = 0 current process = 0 (swapper) [thread pid 0 tid 0 ] Stopped at kobj_lookup_method_mi+0xa: movq0x8(%rdi),%rax db> bt Tracing pid 0 tid 0 td 0x80544000 kobj_lookup_method_mi() at kobj_lookup_method_mi+0xa kobj_lookup_method() at kobj_lookup_method+0x1f acpi_wake_sysctl_walk() at acpi_wake_sysctl_walk+0xc1 acpi_wake_sysctl_walk() at acpi_wake_sysctl_walk+0x74 acpi_wake_sysctl_walk() at acpi_wake_sysctl_walk+0x74 acpi_wake_sysctl_walk() at acpi_wake_sysctl_walk+0x74 acpi_wake_sysctl_walk() at acpi_wake_sysctl_walk+0x74 acpi_wake_sysctl_walk() at acpi_wake_sysctl_walk+0x74 acpi_attach() at acpi_attach+0x984 device_attach() at device_attach+0x69 bus_generic_attach() at bus_generic_attach+0x1a nexus_attach() at nexus_attach+0x19 device_attach() at device_attach+0x69 root_bus_configure() at root_bus_configure+0x28 configure() at configure+0xa mi_startup() at mi_startup+0x59 btext() at btext+0x2c Fatal trap 9: general protection fault while in kernel mode instruction pointer = 0x8:0x8016f8a1 stack pointer = 0x10:0x80611850 frame pointer = 0x10:0x806118d0 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags= interrupt enabled, resume, IOPL = 0 current process = 0 (swapper) [thread pid 0 tid 0 ] Stopped at acpi_wake_sysctl_walk+0xa1: cmpq$0x804f8420,(%rax) db> bt Tracing pid 0 tid 0 td 0x80544000 acpi_wake_sysctl_walk() at acpi_wake_sysctl_walk+0xa1 acpi_wake_sysctl_walk() at acpi_wake_sysctl_walk+0x74 acpi_wake_sysctl_walk() at acpi_wake_sysctl_walk+0x74 acpi_wake_sysctl_walk() at acpi_wake_sysctl_walk+0x74 acpi_wake_sysctl_walk() at acpi_wake_sysctl_walk+0x74 acpi_wake_sysctl_walk() at acpi_wake_sysctl_walk+0x74 acpi_attach() at acpi_attach+0x984 device_attach() at device_attach+0x69 bus_generic_attach() at bus_generic_attach+0x1a nexus_attach() at nexus_attach+0x19 device_attach() at device_attach+0x69 root_bus_configure() at root_bus_configure+0x28 configure() at configure+0xa mi_startup() at mi_startup+0x59 btext() at btext+0x2c Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] [ FreeBSD committer: [EMAIL PROTECTED] ] ---- *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- [EMAIL PROTECTED] *** ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Supermicro PDSMI failed to boot on fresh RELENG_7/amd64
On Wed, 17 Sep 2008, Dmitry Morozovsky wrote: DM> Colleagues, DM> DM> 3 of 4 times this machine failed to boot, panicing somewhere in late kernel DM> initialization phase (before /sbin/init is executed) DM> DM> I have serial console and KDB enabled, so can do experiments. Update: booting GENERIC in single user succeeds, but then after pressing ^D machine stucks running sh very slowly: # ^Dload: 0.56 cmd: sh 57 [runnable] 0.90u 2.72s 18% 1760k load: 0.62 cmd: sh 57 [runnable] 1.41u 5.93s 28% 1760k load: 0.65 cmd: sh 57 [runnable] 1.81u 8.80s 32% 1760k load: 0.99 cmd: ps 61 [runnable] 11.44u 106.73s 36% 1124k load: 0.99 cmd: sh 57 [runnable] 3.63u 24.01s 3% 1760k Loading configuration files. load: 0.99 cmd: sh 57 [runnable] 12.58u 95.10s 37% 1884k (these lines consume 5-10 minutes...) Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] [ FreeBSD committer: [EMAIL PROTECTED] ] -------- *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- [EMAIL PROTECTED] *** ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Supermicro PDSMI failed to boot on fresh RELENG_7/amd64
On Wed, 17 Sep 2008, Jeremy Chadwick wrote:
JC> > 3 of 4 times this machine failed to boot, panicing somewhere in late
kernel
JC> > initialization phase (before /sbin/init is executed)
JC> >
JC> > {snip}
JC>
JC> We have many (specifically, 6) PDSMI+ (not PDSMI) boxes which do not
JC> exhibit this problem.
Next followup: RELENG_7/i386 is working well, only amd64 exhibits problems.
Sincerely,
D.Marck [DM5020, MCK-RIPE, DM3-RIPN]
[ FreeBSD committer: [EMAIL PROTECTED] ]
--------
*** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- [EMAIL PROTECTED] ***
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: RELENG_7 hangs on boot w/Gigabyte MA78GM-S2H MB
On Sat, 20 Sep 2008, Jeremy Chadwick wrote: [snip all] JC> I myself purchased an Asus P5Q SE board, with an Intel Q9550 CPU earlier JC> this week. The board was affordable (barely US$100). One of the JC> reasons I went with this board is because it lacks a) Realtek NICs, b) JC> Broadcom NICs, c) JMicron SATA controllers, and d) Silicon Image SATA JC> controllers. All of those are devices I stay away from. Hmm, side question: why do you hate bge(4)? We have a bunch of gigabit routers/natters with bge, and they perform reasonably well (mostly ASUS M2N-LR mobo)... Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] [ FreeBSD committer: [EMAIL PROTECTED] ] -------- *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- [EMAIL PROTECTED] *** ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
lockd requires statd - is it intentional?
Hi there colleagues, RELENG_7. I found that rpc.lockd can't be started without rpc.statd - it reports Can't start NLM - unable to contact NSM Is this intentional? If so, I suppose appropriate magic should be implemented in /etc/rc.d/lockd (like rpcbind dependency) Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] [ FreeBSD committer: [EMAIL PROTECTED] ] ---- *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- [EMAIL PROTECTED] *** ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
jail: external and localhost distinction
Dear colleagues, am I right concluding that under FreeBSD jail there is no way to attach two processes to the same port of external interface address and localhost? I tried to move rather standard two-tier nginx(ip:80)+apache(127.1:80) scheme into a jail and on apache start got [Thu Jan 29 00:09:32 2009] [crit] (48)Address already in use: make_sock: could not bind to address 127.0.0.1 port 80 (this is under RELENG_7 if it's relevant) Any thoughts? Thanks in advance. -- Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] [ FreeBSD committer: ma...@freebsd.org ] *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- ma...@rinet.ru *** ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: jail: external and localhost distinction
On Thu, 29 Jan 2009, Robert Watson wrote: RW> > am I right concluding that under FreeBSD jail there is no way to attach RW> > two processes to the same port of external interface address and RW> > localhost? RW> > RW> > I tried to move rather standard two-tier nginx(ip:80)+apache(127.1:80) RW> > scheme into a jail and on apache start got RW> > RW> > [Thu Jan 29 00:09:32 2009] [crit] (48)Address already in use: make_sock: RW> > could not bind to address 127.0.0.1 port 80 RW> > RW> > (this is under RELENG_7 if it's relevant) RW> > RW> > Any thoughts? Thanks in advance. RW> RW> The way Jail is implemented is that the jail IP is silently substituted for RW> the loopback IP is used. This has some downsides, and this is one of them. RW> The virtual network stack (VIMAGE) project for FreeBSD 8.0 is intended to RW> address this, among many other things, by providing full virtualization of RW> all network stack data structures for jails. Thank you for clarification, now I see this is actually expected behaviour :) Would then starting second jail with the same root and, say, 127.10.0.1 as an address be a workaround? -- Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] [ FreeBSD committer: ma...@freebsd.org ] *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- ma...@rinet.ru *** ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Xorg hangs on first boot
Colleagues, yes, I'm the next person to report Xorg upgrade problems ;) After thorough upgrade (ugh!!!) almost all work as expected, except one thing: on initial machine boot, X starts, gdm executes -- and then this console is not responded to either keyboard or mouse; however, I can switch to text console, log in and kill X server. After that, everything works correctly. Any hints? Thank you in advance. -- Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] [ FreeBSD committer: ma...@freebsd.org ] *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- ma...@rinet.ru *** ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Xorg hangs on first boot
On Sat, 31 Jan 2009, Johannes Dieterich wrote: JD> | yes, I'm the next person to report Xorg upgrade problems ;) JD> | JD> | After thorough upgrade (ugh!!!) almost all work as expected, except JD> one thing: JD> | JD> | on initial machine boot, X starts, gdm executes -- and then this JD> console is not JD> | responded to either keyboard or mouse; however, I can switch to text JD> console, JD> | log in and kill X server. After that, everything works correctly. JD> | JD> | Any hints? Thank you in advance. JD> JD> Just an idea: I saw excactly this behaviour with my keyboard and mouse JD> (both USB, is this the case for you?) Setting JD> JD> Option "AllowEmptyInput" "off" JD> JD> in xorg.conf as described in UPDATING solved it for me (despite that it JD> should not be needed anymore at all and especially not for keyboards.. :-) ) Nope, that's not my case, as I have PS/2 input devices and do have enabled dbus/hald (I use gnome, so they were enabled anyway) -- Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] [ FreeBSD committer: ma...@freebsd.org ] *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- ma...@rinet.ru *** ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Xorg hangs on first boot
On Sat, 31 Jan 2009, Dominic Fandrey wrote: DF> > After thorough upgrade (ugh!!!) almost all work as expected, except one thing: DF> > DF> > on initial machine boot, X starts, gdm executes -- and then this console is not DF> > responded to either keyboard or mouse; however, I can switch to text console, DF> > log in and kill X server. After that, everything works correctly. DF> > DF> > Any hints? Thank you in advance. DF> > DF> DF> You are facing the same problem as Oliver. Your X starts before the connection DF> between hald und dbus is established and hence X does not find hald. Well, but gdm rc.d script contains # REQUIRE: LOGIN cleanvar moused syscons dbus hald and console log shows correct order: Jan 31 13:53:49 revamp kernel: Starting dbus. Jan 31 13:53:50 revamp kernel: Starting hald. Jan 31 13:53:50 revamp kernel: Configuring syscons: Jan 31 13:53:50 revamp kernel: blanktime Jan 31 13:53:50 revamp kernel: . Jan 31 13:53:50 revamp kernel: Starting gdm. Rather strange for me. -- Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] [ FreeBSD committer: ma...@freebsd.org ] -------- *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- ma...@rinet.ru *** ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Xorg hangs on first boot
On Sat, 31 Jan 2009, Dominic Fandrey wrote: DF> > DF> You are facing the same problem as Oliver. Your X starts before the connection DF> > DF> between hald und dbus is established and hence X does not find hald. DF> > DF> > Well, but gdm rc.d script contains DF> > DF> > # REQUIRE: LOGIN cleanvar moused syscons dbus hald DF> > DF> > and console log shows correct order: ...> DF> > Rather strange for me. DF> > DF> DF> Yes, they start in the correct order, but the connection between them is not done DF> in time. This is a conceptual problem that can only be fixed properly upstream in DF> Xorg (the problem also exists with Linux distributions). The only workaround that DF> comes to mind is to operate X without hald or delay the start of gdm. Ah, I see detached cycle that waits not more than 60 seconds and does not probe hald. -- Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] [ FreeBSD committer: ma...@freebsd.org ] ---- *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- ma...@rinet.ru *** ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: jail: external and localhost distinction
On Fri, 6 Feb 2009, Robert Watson wrote: RW> > Thank you for clarification, now I see this is actually expected behaviour RW> > :) RW> > RW> > Would then starting second jail with the same root and, say, 127.10.0.1 as RW> > an address be a workaround? RW> RW> There's no technical reason you can't have more than one jail using the same RW> file system root, and even IP -- you'll find that ps(1) in one jail can't RW> see processes in the other (and can't signal, etc) but otherwise works as RW> expected. Of course, any given process has to be a member of at most one of RW> the two. But, in the case of IP sharing, I suppose, the second process tries to bind to the same port will got "socket already in use", won't it? -- Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] [ FreeBSD committer: ma...@freebsd.org ] ---- *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- ma...@rinet.ru *** ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Upgrade from 32-bit to AMD-64?
On Wed, 18 Feb 2009, Karl Denninger wrote: KD> I have been able to come up with a procedure that works. KD> KD> 1. Load a new hard disk with the 64-bit code. Perform a buildworld and KD> buildkernel, and installkernel and installworld to this disk to verify that KD> it will install and run. You now have a "base" disk to use for migration. KD> KD> 2. Make sure you have a backup (:-)) KD> KD> 3. Boot the migration hard disk as the system disk and mount the subject KD> machine's disk drive(s) under /mnt. KD> KD> 4. Do "make DESTDIR=/mnt installkernel" and "make DESTDIR=/mnt installworld" KD> KD> 5. Shut down and disconnect migration disk. KD> KD> 6. Boot SINGLE USER and verify that the system boots, you can fsck -p the KD> disks, and mount them. The system should boot and run. KD> KD> 7. Come up multiuser but with any services necessary to the world offline. KD> Some of your packages may blow up when started. If so, portupgrade SHOULD KD> fix it, but this is not consistent. I had to manually dump the ports tree KD> and rebuild a few installed ports due to what appear to be broken KD> dependancies, but not many. KD> KD> Postgresql 32-bit runs fine without recompilation after doing this. It is KD> arguably preferrable to recompile; doing so requires a dump/restore of the KD> data as the 32 and 64-bit code will NOT run off the same binary data store. KD> KD> Attempting to "make instalkernel" on an "in-place" basis resulted in a KD> system that booted but failed immediately due to loader conflicts; there was KD> no way to get the rest of the codeset loaded if you make that mistake. You can avoid most of these problems if you have copies of ld-elf (both 32-bit and 64-bit), and boot single user for /rescue; however, "migration disk" approach is much simpler. KD> KD> The "migration disk" approach appears to work fine. -- Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] [ FreeBSD committer: ma...@freebsd.org ] *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- ma...@rinet.ru *** ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
RELENG_7: gdm after portupgrade does not allow logins
Dear colleagues,
after portupgrade'ing on last gnome update I have very strange situation:
gdm does not show neither login list not username text field; after pressing
space, some unlabelled text field opens (symbols are echoed, so I suppose it's
like login name field); however, entering anything there does not lead
anywhere.
portupgrade -f gdm does not help; portupgrade -f ${direct gdm dependencies}
does not help, either.
And, of course, I even rebooted the machine without a bit of success.
Any hints? Thanks in advance!
--
Sincerely,
D.Marck [DM5020, MCK-RIPE, DM3-RIPN]
[ FreeBSD committer: ma...@freebsd.org ]
----
*** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- ma...@rinet.ru ***
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
ZFS zpool stall on RELENG_8
Dear colleagues, after some unidenfified trouble I am no longer able to access raidz1 pool on my home file server (8 sata disks). rebooting from outer media works fine until `zpool import' - then process is stuck in zio->io_cv state forever (I waited for 2+ hours) without real activity. This is reproducible on both amd64 and i386. Any hints? Thanks in advance! -- Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] [ FreeBSD committer: ma...@freebsd.org ] ---- *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- ma...@rinet.ru *** ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: ZFS zpool stall on RELENG_8
On Sat, 16 Jan 2010, Dmitry Morozovsky wrote: DM> after some unidenfified trouble I am no longer able to access raidz1 pool on my DM> home file server (8 sata disks). rebooting from outer media works fine until DM> `zpool import' - then process is stuck in zio->io_cv state forever (I waited DM> for 2+ hours) without real activity. This is reproducible on both amd64 and DM> i386. DM> DM> Any hints? Thanks in advance! well, I just booted from fresh stable/8/amd64 with DDB compiled in. what info should I extract from kernel debugger? -- Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] [ FreeBSD committer: ma...@freebsd.org ] -------- *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- ma...@rinet.ru *** ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: make buildkernel failing on zfs
On Fri, 22 Jan 2010, Ruben de Groot wrote: RdG> > Could you post your /etc/make.conf? RdG> > That said, I recon you build your kernel in a rather wierd way. Delete RdG> > /usr/obj/* and run "make cleandir && make cleandir" in /usr/src. Then RdG> RdG> Bit redundant ;) RdG> cleandir only effects /usr/obj, which you just blew away. Not exactly: without objdir, cleandir removes built objects from source directory (where they may accidentally reside if one type 'make all' without 'make obj' previously) -- Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] [ FreeBSD committer: ma...@freebsd.org ] -------- *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- ma...@rinet.ru *** ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
ZFS panic on RELENG_7/i386
Dear colleagues, I had a crash durinc rsync to ZFS today: (kgdb) bt #0 doadump () at pcpu.h:196 #1 0xc050c688 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:418 #2 0xc050c965 in panic (fmt=Variable "fmt" is not available. ) at /usr/src/sys/kern/kern_shutdown.c:574 #3 0xc08e95ce in zfs_fuid_create (zfsvfs=0xc65c4800, id=Unhandled dwarf expression opcode 0x93 ) at /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_fuid.c:591 #4 0xc0910775 in zfs_freebsd_setattr (ap=0xf5baab64) at /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c:2888 #5 0xc06c6292 in VOP_SETATTR_APV (vop=0xc096e560, a=0xf5baab64) at vnode_if.c:583 #6 0xc05918e5 in setfown (td=0xc834fd80, vp=0xcac4b33c, uid=4294967294, gid=0) at vnode_if.h:315 #7 0xc05919bc in kern_lchown (td=0xc834fd80, path=0xbfbfccc8 , pathseg=UIO_USERSPACE, uid=-2, gid=0) at /usr/src/sys/kern/vfs_syscalls.c:2787 #8 0xc0591a4a in lchown (td=0xc834fd80, uap=0xf5baacfc) at /usr/src/sys/kern/vfs_syscalls.c:2770 #9 0xc06b10f5 in syscall (frame=0xf5baad38) at /usr/src/sys/i386/i386/trap.c:1101 #10 0xc0696b90 in Xint0x80_syscall () at /usr/src/sys/i386/i386/exception.s:262 Any other info needed? Thanks in advance! -- Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] [ FreeBSD committer: ma...@freebsd.org ] ---- *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- ma...@rinet.ru *** ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: ZFS panic on RELENG_7/i386
On Mon, 25 Jan 2010, Pawel Jakub Dawidek wrote: PJD> On Mon, Jan 25, 2010 at 10:04:20PM +0300, Dmitry Morozovsky wrote: PJD> > Dear colleagues, PJD> > PJD> > I had a crash durinc rsync to ZFS today: PJD> PJD> Do you have recent 7-STABLE? Not sure if it was the same before MFC, r...@woozle:/var/crash# uname -a FreeBSD woozle.rinet.ru 7.2-STABLE FreeBSD 7.2-STABLE #4: Mon Dec 14 12:40:43 MSK 2009 ma...@woozle.rinet.ru:/usr/obj/usr/src/sys/WOOZLE i386 I'll update to fresh sources and recheck, thanks. BTW, any thoughts of another topic I started a couple of weeks ago? PJD> probably not, because what you see is impossible in case of source I'm PJD> looking at. At the begining of zfs_fuid_create() function there is a PJD> check: PJD> PJD>if (!zfsvfs->z_use_fuids || !IS_EPHEMERAL(id) || fuid_idx != 0) PJD>return (id); PJD> PJD> And IS_EPHEMERAL() is defined as follows: PJD> PJD>#define IS_EPHEMERAL(x) (0) PJD> PJD> So it will always return here. PJD> PJD> > #3 0xc08e95ce in zfs_fuid_create (zfsvfs=0xc65c4800, id=Unhandled dwarf PJD> > expression opcode 0x93 PJD> > ) PJD> > at PJD> > /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_fuid.c:591 PJD> PJD> -- Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] [ FreeBSD committer: ma...@freebsd.org ] *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- ma...@rinet.ru *** ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: ZFS panic on RELENG_7/i386
On Mon, 25 Jan 2010, Dmitry Morozovsky wrote: DM> PJD> > I had a crash durinc rsync to ZFS today: DM> PJD> DM> PJD> Do you have recent 7-STABLE? Not sure if it was the same before MFC, DM> DM> r...@woozle:/var/crash# uname -a DM> FreeBSD woozle.rinet.ru 7.2-STABLE FreeBSD 7.2-STABLE #4: Mon Dec 14 12:40:43 DM> MSK 2009 ma...@woozle.rinet.ru:/usr/obj/usr/src/sys/WOOZLE i386 DM> DM> I'll update to fresh sources and recheck, thanks. DM> DM> BTW, any thoughts of another topic I started a couple of weeks ago? Well, after updating to fresh system scrub finished without errors, and now rsync is running, now copied 15G out of 150. Thank you! -- Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] [ FreeBSD committer: ma...@freebsd.org ] -------- *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- ma...@rinet.ru *** ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: ZFS panic on RELENG_7/i386
On Tue, 26 Jan 2010, Alexander Leidinger wrote: AL> > Well, after updating to fresh system scrub finished without errors, and AL> > now AL> > rsync is running, now copied 15G out of 150. AL> AL> You may want to switch the checksum algorithm to fletcher4. It (fletcher4 AL> the default instead of fletcher2) is one of the few changes between 8-stable AL> and 7-stable in ZFS, which I didn't merge. will do, thank you. is fletcher4 faster? -- Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] [ FreeBSD committer: ma...@freebsd.org ] -------- *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- ma...@rinet.ru *** ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Another ZFS RELENG_7/i386 strangeness: Operation not permitted
Dear colleagues, stable/7 as of yesterday. Operation not permitted errors during `rsync -avH --fileflags' to ZFS. Investigating: r...@woozle:/usr/ports# la -io /w/backup/woozle/var/log/www/woozle/.access_log.9.gz.* 73613 -rw-r--r-- 1 root wheel - 1200326 Sep 25 2005 /w/backup/woozle/var/log/www/woozle/.access_log.9.gz.bg9Zcw 73728 -rw-r--r-- 1 root wheel - 1200326 Sep 25 2005 /w/backup/woozle/var/log/www/woozle/.access_log.9.gz.dxux3T 28355 -rw-r--r-- 1 root wheel - 1200326 Sep 25 2005 /w/backup/woozle/var/log/www/woozle/.access_log.9.gz.wxuWSQ r...@woozle:/usr/ports# rm -f !$ rm -f /w/backup/woozle/var/log/www/woozle/.access_log.9.gz.* rm: /w/backup/woozle/var/log/www/woozle/.access_log.9.gz.bg9Zcw: Operation not permitted rm: /w/backup/woozle/var/log/www/woozle/.access_log.9.gz.dxux3T: Operation not permitted rm: /w/backup/woozle/var/log/www/woozle/.access_log.9.gz.wxuWSQ: Operation not permitted zfs umount/mount does not fix the problem. turning on vfs.zfs.debug does not reveal anything. WTF? (sorry ;) I'm puzzled. -- Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] [ FreeBSD committer: ma...@freebsd.org ] ---- *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- ma...@rinet.ru *** ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: ZFS panic on RELENG_7/i386
On Tue, 26 Jan 2010, Artem Belevich wrote: AB> > will do, thank you. is fletcher4 faster? AB> Not necessarily. But it does work as a checksum much better. See AB> following link for the details. AB> AB> http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=6740597 Yes, I already read some articles about fletcher checksums and related. Thanks. -- Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] [ FreeBSD committer: ma...@freebsd.org ] -------- *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- ma...@rinet.ru *** ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Another ZFS RELENG_7/i386 strangeness: Operation not permitted
On Tue, 26 Jan 2010, Dmitry Morozovsky wrote: DM> Dear colleagues, DM> DM> stable/7 as of yesterday. Operation not permitted errors during DM> `rsync -avH --fileflags' to ZFS. Investigating: DM> DM> r...@woozle:/usr/ports# la -io DM> /w/backup/woozle/var/log/www/woozle/.access_log.9.gz.* DM> 73613 -rw-r--r-- 1 root wheel - 1200326 Sep 25 2005 /w/backup/woozle/var/log/www/woozle/.access_log.9.gz.bg9Zcw DM> 73728 -rw-r--r-- 1 root wheel - 1200326 Sep 25 2005 /w/backup/woozle/var/log/www/woozle/.access_log.9.gz.dxux3T DM> 28355 -rw-r--r-- 1 root wheel - 1200326 Sep 25 2005 /w/backup/woozle/var/log/www/woozle/.access_log.9.gz.wxuWSQ DM> r...@woozle:/usr/ports# rm -f !$ DM> rm -f /w/backup/woozle/var/log/www/woozle/.access_log.9.gz.* DM> rm: /w/backup/woozle/var/log/www/woozle/.access_log.9.gz.bg9Zcw: Operation not permitted DM> rm: /w/backup/woozle/var/log/www/woozle/.access_log.9.gz.dxux3T: Operation not permitted DM> rm: /w/backup/woozle/var/log/www/woozle/.access_log.9.gz.wxuWSQ: Operation not permitted DM> DM> zfs umount/mount does not fix the problem. turning on vfs.zfs.debug does not DM> reveal anything. DM> DM> WTF? (sorry ;) I'm puzzled. found the source: it's sunlnk flag on a directory, which behaves differently on UFS and ZFS: on UFS, this flag does not prevent removing files from the directory, only removing and renaming directory itself. Should I file a PR? -- Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] [ FreeBSD committer: ma...@freebsd.org ] -------- *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- ma...@rinet.ru *** ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Another ZFS RELENG_7/i386 strangeness: Operation not permitted
On Tue, 26 Jan 2010, Dmitry Morozovsky wrote: DM> DM> stable/7 as of yesterday. Operation not permitted errors during DM> DM> `rsync -avH --fileflags' to ZFS. Investigating: DM> DM> DM> DM> r...@woozle:/usr/ports# la -io DM> DM> /w/backup/woozle/var/log/www/woozle/.access_log.9.gz.* DM> DM> 73613 -rw-r--r-- 1 root wheel - 1200326 Sep 25 2005 /w/backup/woozle/var/log/www/woozle/.access_log.9.gz.bg9Zcw DM> DM> 73728 -rw-r--r-- 1 root wheel - 1200326 Sep 25 2005 /w/backup/woozle/var/log/www/woozle/.access_log.9.gz.dxux3T DM> DM> 28355 -rw-r--r-- 1 root wheel - 1200326 Sep 25 2005 /w/backup/woozle/var/log/www/woozle/.access_log.9.gz.wxuWSQ DM> DM> r...@woozle:/usr/ports# rm -f !$ DM> DM> rm -f /w/backup/woozle/var/log/www/woozle/.access_log.9.gz.* DM> DM> rm: /w/backup/woozle/var/log/www/woozle/.access_log.9.gz.bg9Zcw: Operation not permitted DM> DM> rm: /w/backup/woozle/var/log/www/woozle/.access_log.9.gz.dxux3T: Operation not permitted DM> DM> rm: /w/backup/woozle/var/log/www/woozle/.access_log.9.gz.wxuWSQ: Operation not permitted DM> DM> DM> DM> zfs umount/mount does not fix the problem. turning on vfs.zfs.debug does not DM> DM> reveal anything. DM> DM> found the source: it's sunlnk flag on a directory, which behaves differently on DM> UFS and ZFS: on UFS, this flag does not prevent removing files from the directory, only DM> removing and renaming directory itself. DM> DM> Should I file a PR? For the reference: http://www.freebsd.org/cgi/query-pr.cgi?pr=143343 -- Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] [ FreeBSD committer: ma...@freebsd.org ] *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- ma...@rinet.ru *** ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: hardware for home use large storage
On Mon, 8 Feb 2010, Dan Langille wrote: DL> I'm looking at creating a large home use storage machine. Budget is a DL> concern, but size and reliability are also a priority. Noise is also a DL> concern, since this will be at home, in the basement. That, and cost, DL> pretty much rules out a commercial case, such as a 3U case. It would be DL> nice, but it greatly inflates the budget. This pretty much restricts me to DL> a tower case. [snip] We use the following at work, but it's still pretty cheap and pretty silent: Chieftec WH-02B-B (9x5.25 bays) filled with 2 x Supermicro CSE-MT35T http://www.supermicro.nl/products/accessories/mobilerack/CSE-M35T-1.cfm for regular storage, 2 x raidz1 1 x Promise SuperSwap 1600 http://www.promise.com/product/product_detail_eng.asp?product_id=169 for changeable external backups and still have 2 5.25 bays for anything interesting ;-) other parts are regular SocketAM2+ motherboard, Athlon X4, 8G ram, FreeBSD/amd64 -- Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] [ FreeBSD committer: ma...@freebsd.org ] -------- *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- ma...@rinet.ru *** ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: hardware for home use large storage
On Wed, 10 Feb 2010, Dmitry Morozovsky wrote: DM> other parts are regular SocketAM2+ motherboard, Athlon X4, 8G ram, DM> FreeBSD/amd64 well, not exactly "regular" - it's ASUS M2N-LR-SATA with 10 SATA channels, but I suppose there are comparable in "workstation" mobo market now... -- Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] [ FreeBSD committer: ma...@freebsd.org ] -------- *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- ma...@rinet.ru *** ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: hardware for home use large storage
On Wed, 10 Feb 2010, Dan Langille wrote: DL> Dmitry Morozovsky wrote: DL> > On Wed, 10 Feb 2010, Dmitry Morozovsky wrote: DL> > DL> > DM> other parts are regular SocketAM2+ motherboard, Athlon X4, 8G ram, DM> DL> > FreeBSD/amd64 DL> > DL> > well, not exactly "regular" - it's ASUS M2N-LR-SATA with 10 SATA channels, DL> > but I suppose there are comparable in "workstation" mobo market now... DL> DL> 10 SATA channels? Newegg claims only 6: You refer to regular M2N-LR, M2N-LR-SATA contains additional 4-channel Marvell chip: ma...@moose:~> grep '^atapci.*: <' /var/run/dmesg.boot atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xffa0-0xffaf at device 4.0 on pci0 atapci1: port 0xc400-0xc407,0xc080-0xc083,0xc000-0xc007,0xbc00-0xbc03,0xb880-0xb88f mem 0xef9bd000-0xef9bdfff irq 21 at device 5.0 on pci0 atapci2: port 0xb800-0xb807,0xb480-0xb483,0xb400-0xb407,0xb080-0xb083,0xb000-0xb00f mem 0xef9bc000-0xef9bcfff irq 22 at device 5.1 on pci0 atapci3: port 0xac00-0xac07,0xa880-0xa883,0xa800-0xa807,0xa480-0xa483,0xa400-0xa40f mem 0xef9b3000-0xef9b3fff irq 23 at device 5.2 on pci0 atapci4: port 0xe800-0xe8ff mem 0xefd0-0xefdf irq 17 at device 0.0 on pci3 atapci5: port 0xe400-0xe4ff mem 0xefb0-0xefbf irq 18 at device 6.0 on pci3 (atapci4 is now used for 1-disk Promise enclosure; I tried to use SiL card to use eSATA port native, but it failed to initialize there, so I use simple SATA-eSATA bracket to use eSATA capabilities to this Eternal Beast [tm] ;-P) -- Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] [ FreeBSD committer: ma...@freebsd.org ] *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- ma...@rinet.ru *** ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: hardware for home use large storage
On Sun, 14 Feb 2010, Dan Langille wrote: [snip] DL> > SAS controller ($120): DL> > http://www.buy.com/prod/supermicro-lsi-megaraid-lsisas1068e-8-port-sas-raid-controller-16mb/q/loc/101/207929556.html DL> > Note: You'll need to change or remove the mounting bracket since it is DL> > "backwards". I was able to find a bracket with matching screw holes on an DL> > old nic and secure it to my case. It uses the same chipset as the more DL> > expensive 3081E-R, if I remember correctly. DL> DL> I follow what you say, but cannot comprehend why the bracket is backwards. It's because IO slot is ot the other side of the bracked, like good old ISA -- Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] [ FreeBSD committer: ma...@freebsd.org ] -------- *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- ma...@rinet.ru *** ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: hardware for home use large storage
On Mon, 15 Feb 2010, Dan Naumov wrote: DN> >> PSU: Corsair 400CX 80+ - 59 euro - DN> > DN> >> http://www.corsair.com/products/cx/default.aspx DN> > DN> > http://www.newegg.com/Product/Product.aspx?Item=N82E16817139008 for $50 DN> > DN> > Is that sufficient power up to 10 SATA HDD and an optical drive? DN> DN> Disk power use varies from about 8 watt/disk for "green" disks to 20 DN> watt/disk for really powerhungry ones. So yes. The only thing one should be aware that startup current on contemporary 3.5 SATA disks would exceed 2.5A on 12V buse, so delaying plate startup is rather vital. Or get 500-520 VA PSU to be sure. Or do both just to be on the safe side ;-) -- Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] [ FreeBSD committer: ma...@freebsd.org ] -------- *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- ma...@rinet.ru *** ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: hardware for home use large storage
On Mon, 15 Feb 2010, Artem Belevich wrote: AB> It used to be that vm.kmem_size_max needed to be bumped to allow for AB> larger vm.kmem_size. It's no longer needed on amd64. Not sure about AB> i386. AB> AB> vm.kmem_size still needs tuning, though. While vm.kmem_size_max is no AB> longer a limit, there are other checks in place that result in default AB> vm.kmem_size being a bit on the conservative side for ZFS. it seems so at least: on a machine with 8G RAM kmem_size is set to 2G, from which 1.5G is allocated for arc_max. I'll try to increase them to 4G / 3G and test whether machine is stable... -- Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] [ FreeBSD committer: ma...@freebsd.org ] -------- *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- ma...@rinet.ru *** ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: hardware for home use large storage
On Mon, 15 Feb 2010, jfar...@goldsword.com wrote: > > Just out of curiousity, would not an older server like this: > http://www.geeks.com/details.asp?InvtId=DL145-5R (~$75 + shipping) or > http://www.geeks.com/details.asp?invtid=DL360-6R&cat=SYS (~$190 + shipping) > > be a reasonable option? Unless you're looking to suck every last bit of speed > or energy savings out the machine, I would think bumping the memory up on one > of these, adding one or more eSATA or SAS interfaces and an external drive > rack would result in an exceptional "home" server with several TB of storage, > decent speed, still costing less than $1K usd way too noisy, even for the basement :( -- Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] [ FreeBSD committer: ma...@freebsd.org ] -------- *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- ma...@rinet.ru *** ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
7.0-PRE/amd64 crash with Promise TX4 and eSATA disk
Dear colleagues, during rsycn from eSATA drive connected to Promise TX4 (ad12) to ZFS pool eSATA disk got disconnected. With the next access, system crashed: Unread portion of the kernel message buffer: Fatal trap 12: page fault while in kernel mode cpuid = 1; apic id = 01 fault virtual address = 0x3020e0b30 fault code = supervisor read data, page not present instruction pointer = 0x8:0x801cac9d stack pointer = 0x10:0xd79f7800 frame pointer = 0x10:0xd79f7840 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags= interrupt enabled, resume, IOPL = 0 current process = 898 (tcsh) trap number = 12 panic: page fault cpuid = 1 Uptime: 7h49m35s Physical memory: 4087 MB Dumping 677 MB: 662 646 630 614 598 582 566 550 534 518 502 486 470 454 438 422 406 390 374 358 342 326 310 294 278 262 246 230 214 198 182 166 150 134 118 102 86 70 54 38 22 6 #0 doadump () at pcpu.h:194 194 pcpu.h: No such file or directory. in pcpu.h (kgdb) bt #0 doadump () at pcpu.h:194 #1 0x0031 in ?? () #2 0x80219c30 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:409 #3 0x8021a04d in panic (fmt=0x104 ) at /usr/src/sys/kern/kern_shutdown.c:563 #4 0x80353284 in trap_fatal (frame=0xff000179c340, eva=18446742974222725120) at /usr/src/sys/amd64/amd64/trap.c:724 #5 0x80353655 in trap_pfault (frame=0xd79f7750, usermode=0) at /usr/src/sys/amd64/amd64/trap.c:641 #6 0x80353ffb in trap (frame=0xd79f7750) at /usr/src/sys/amd64/amd64/trap.c:410 #7 0x80339dbe in calltrap () at /usr/src/sys/amd64/amd64/exception.S:169 #8 0x801cac9d in dev2udev (x=0xff0001779400) at /usr/src/sys/fs/devfs/devfs_vnops.c:1325 #9 0x80310ab8 in ufs_getattr (ap=Variable "ap" is not available. ) at /usr/src/sys/ufs/ufs/ufs_vnops.c:401 #10 0x8029dcf3 in vn_stat (vp=0xff004728b9b0, sb=0xd79f79f0, active_cred=Variable "active_cred" is not available. ) at vnode_if.h:286 #11 0x802953b1 in kern_stat (td=0xff000179c340, path=0x44b66a , pathseg=Variable "pathseg" is not available. ) at /usr/src/sys/kern/vfs_syscalls.c:2112 #12 0x80295507 in stat (td=Variable "td" is not available. ) at /usr/src/sys/kern/vfs_syscalls.c:2093 #13 0x803538da in syscall (frame=0xd79f7c70) at /usr/src/sys/amd64/amd64/trap.c:852 #14 0x80339fcb in Xfast_syscall () at /usr/src/sys/amd64/amd64/exception.S:290 #15 0x809c235c in ?? () Previous frame inner to this frame (corrupt stack?) (kgdb) I would be glad to provide additional info to investigate and hopefully fix the problem. Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] [ FreeBSD committer: [EMAIL PROTECTED] ] -------- *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- [EMAIL PROTECTED] *** ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: 7.0-PRE/amd64 crash with Promise TX4 and eSATA disk
On Sun, 3 Feb 2008, Kostik Belousov wrote:
KB> Di you have the UFS volume mounted from the eSATA drive ? If yes, then the
KB> panic is the natural consequence of the device disappearing from under the
KB> UFS. If not, and fault address 0x3020e0b30 looks suspicious, it could mean
KB> some kernel memory corruption.
yes, there is (were) UFS2 on eSATA.
KB> Anyway, it would be interesting to look at the vnode vp content from the
KB> frame #10, and to lookup the mount point together with a device it comes
KB> from.
(kgdb) fr 10
#10 0x8029dcf3 in vn_stat (vp=0xff004728b9b0,
sb=0xd79f79f0, active_cred=Variable "active_cred" is not available.
) at vnode_if.h:286
286 vnode_if.h: No such file or directory.
in vnode_if.h
(kgdb) p vp
$1 = (struct vnode *) 0xff004728b9b0
(kgdb) p *vp
$2 = {v_type = VDIR, v_tag = 0x8039319c "ufs", v_op =
0x804e98e0, v_data = 0xff003fab0480, v_mount = 0xff00050dc650,
v_nmntvnodes = {
tqe_next = 0xff004728bba0, tqe_prev = 0xff004728f218}, v_un =
{vu_mount = 0x0, vu_socket = 0x0, vu_cdev = 0x0, vu_fifoinfo = 0x0}, v_hashlist
= {le_next = 0x0,
le_prev = 0x808c10e0}, v_hash = 215211, v_cache_src = {lh_first =
0xff003f4d5000}, v_cache_dst = {tqh_first = 0xff0026fcca90, tqh_last =
0xff0026fccab0},
v_dd = 0xff00470a49b0, v_cstart = 0, v_lasta = 0, v_lastw = 0, v_clen =
0, v_lock = {lk_object = {lo_name = 0x8039319c "ufs", lo_type =
0x8039319c "ufs",
lo_flags = 70844416, lo_witness_data = {lod_list = {stqe_next = 0x0},
lod_witness = 0x0}}, lk_interlock = 0x80514730, lk_flags = 262208,
lk_sharecount = 0,
lk_waitcount = 0, lk_exclusivecount = 1, lk_prio = 80, lk_timo = 51,
lk_lockholder = 0xff000179c340, lk_newlock = 0x0}, v_interlock =
{lock_object = {
lo_name = 0x8039e4da "vnode interlock", lo_type =
0x8039e4da "vnode interlock", lo_flags = 16973824, lo_witness_data =
{lod_list = {stqe_next = 0x0},
lod_witness = 0x0}}, mtx_lock = 4, mtx_recurse = 0}, v_vnlock =
0xff004728ba48, v_holdcnt = 3, v_usecount = 2, v_iflag = 0, v_vflag = 0,
v_writecount = 0,
v_freelist = {tqe_next = 0x0, tqe_prev = 0xff004728b900}, v_bufobj =
{bo_mtx = 0xff004728ba98, bo_clean = {bv_hd = {tqh_first = 0x0, tqh_last =
0xff004728bb08},
bv_root = 0x0, bv_cnt = 0}, bo_dirty = {bv_hd = {tqh_first = 0x0,
tqh_last = 0xff004728bb28}, bv_root = 0x0, bv_cnt = 0}, bo_numoutput = 0,
bo_flag = 0,
bo_ops = 0x804dd3e0, bo_bsize = 65536, bo_object =
0xff0047994680, bo_synclist = {le_next = 0x0, le_prev = 0x0}, bo_private =
0xff004728b9b0,
__bo_vnode = 0xff004728b9b0}, v_pollinfo = 0x0, v_label = 0x0}
I think tere are at least two problems here:
- panic when non-essential UFS mounted partition disappears
- particular disappearing eSATA drive from eSATA channel of TX4. Relevant error
messages are
Feb 2 19:29:18 hamster kernel: ata7: reiniting channel ..
Feb 2 19:29:18 hamster kernel: ata7: SATA connect time=0ms
Feb 2 19:29:18 hamster kernel: ata7: reset tp1 mask=01 ostat0=d0
ostat1=00
Feb 2 19:29:18 hamster kernel: ata7: stat0=0xd0 err=0x00 lsb=0x36
msb=0x72
Feb 2 19:29:26 hamster last message repeated 87 times
Feb 2 19:29:27 hamster kernel:
Feb 2 19:29:27 hamster kernel: ata7: stat0=0xd0 err=0x00 lsb=0x36
msb=0x72
Feb 2 19:29:49 hamster last message repeated 221 times
Feb 2 19:29:49 hamster kernel: ata7: reset tp2 stat0=d0 stat1=00
devices=0x0
Feb 2 19:29:49 hamster kernel: ad14: FAILURE - device detached
Feb 2 19:29:49 hamster kernel: ad1g4_:v fdse_tdaocnhee(d):
Feb 2 19:29:49 hamster kernel: ad14a[aRtEaA7D:( orfefisneitt=
d1o2n4e0 9.1.43
Feb 2 19:29:49 hamster kernel: 2960, length=131072)]error = 6
Feb 2 19:29:49 hamster kernel:
g_vfs_done():ad14a[READ(offset=124091564032, length=131072)]error = 6
Feb 2 19:29:49 hamster kernel:
g_vfs_done():ad14a[READ(offset=124091695104, length=131072)]error = 6
... and zillion of g_vfs_gone after.
Sincerely,
D.Marck [DM5020, MCK-RIPE, DM3-RIPN]
[ FreeBSD committer: [EMAIL PROTECTED] ]
--------
*** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- [EMAIL PROTECTED] ***
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: 7.0-PRE/amd64 crash with Promise TX4 and eSATA disk
On Sun, 3 Feb 2008, Kostik Belousov wrote:
KB> > (kgdb) p *vp
KB> > $2 = {v_type = VDIR, v_tag = 0x8039319c "ufs", v_op =
KB> > 0x804e98e0, v_data = 0xff003fab0480, v_mount =
0xff00050dc650,
KB> The *v_mount and *(struct ufs_mount *)(v_mount->mnt_data) content shall
KB> be enough to confirm that vnode comes from the lost partition.
sure:
...
f_mntfromname = "/dev/ad14a",
f_mntonname = "/media/esata",
but I was sure it was from there.
KB> > I think tere are at least two problems here:
KB> > - panic when non-essential UFS mounted partition disappears
KB> Unfortunately, FreeBSD has no concept of the unessential mount; I wish
KB> the mount option onerror=nopanic too :).
What disturbs me even more - mount was read-only. I can understand the
"panic when some unwritten data may be lost" approach, but on read-only...
KB> > - particular disappearing eSATA drive from eSATA channel of TX4. Relevant
error
KB> > messages are
KB> This looks more like the hardware problem, and it only induced the known
KB> kernel deficiency.
That's why I put Soeren on CC list ;)
Sincerely,
D.Marck [DM5020, MCK-RIPE, DM3-RIPN]
[ FreeBSD committer: [EMAIL PROTECTED] ]
*** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- [EMAIL PROTECTED] ***
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Very large kernel
On Sat, 1 Mar 2008, Kris Kennaway wrote: KK> Alex de Kruijff wrote: KK> > I noticed that the kernel directory was very large compaired to 6.1. Is KK> > this for debugging and can I safely remove the symbols files I want to KK> > save some space? KK> KK> Yes but if you encounter a panic and need to submit a bug report then you KK> will need at least the kernel.debug and whatever modules you are using. What about gzipping .symbol files by default? It decreases symbol files size in about 50-60%, so i386 GENERIC kernel directory shrinks from 125m to 74m... Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] [ FreeBSD committer: [EMAIL PROTECTED] ] -------- *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- [EMAIL PROTECTED] *** ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: moused freezes Xorg - caused by compiler bug
On Thu, 20 Mar 2008, Dominic Fandrey wrote:
DF> I have long been annoyed by the problem that Xorg is frozen if I use moused,
DF> unless the mouse is in movement. Just imagine you type something and it only
DF> shows up when you move your mouse. Or if you watch a video ... you basically
DF> have to keep the mouse in movement all the time.
DF>
DF> I am/have been using the following CPUTYPEs on different machines:
DF> pentium4 - not affected
DF> pentium-m - affected
DF> core2/nocona - affected
DF>
DF> I just had the idea this might be an optimization problem and I rebuild
DF> src/usr.sbin/moused with CPUTYPE=athlon64 and it works.
DF>
DF> I've put the following into my make.conf:
DF>
DF> # moused bug workaround
DF> .if ${.CURDIR:M*/usr.sbin/moused}
DF> .if defined(CPUTYPE)
DF> .if ${CPUTYPE} == core2
DF> CPUTYPE=athlon64
DF> .elif ${CPUTYPE} == pentium-m
DF> CPUTYPE=pentium3
DF> .endif
DF> .endif
DF> .endif
On my home machine (A64 X2) moused causes freezes with CPUTYPEs k8 and i686 too.
Sincerely,
D.Marck [DM5020, MCK-RIPE, DM3-RIPN]
[ FreeBSD committer: [EMAIL PROTECTED] ]
--------
*** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- [EMAIL PROTECTED] ***
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ZFS version 8 on stable?
On Fri, 13 Jun 2008, Kris Kennaway wrote: KK> It is planned to update to a newer ZFS release in HEAD, but this has not KK> happened yet (let alone in 7.x). I don't know if it is possible to KK> downgrade a pool - you should check the ZFS documentation/support materials. It seems there is no such way; what is worse, it also seems there's no way to create a pool with lower pool version. Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] [ FreeBSD committer: [EMAIL PROTECTED] ] -------- *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- [EMAIL PROTECTED] *** ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ZFS version 8 on stable?
On Sat, 28 Jun 2008, Dillon wrote: D> > KK> happened yet (let alone in 7.x). I don't know if it is possible to D> > KK> downgrade a pool - you should check the ZFS documentation/support D> > materials. D> > D> > It seems there is no such way; what is worse, it also seems there's no way D> > to create a pool with lower pool version. D> ZFS On Mac OSX creates zfs v6 pools by default (in order to retain compat D> with the stock read-only zfs v6 module in 10.5) which work fine with FreeBSD. D> Just don't upgrade the pool on OS-X after creating it. Ah, that is much better. Thank you for clarifying. Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] [ FreeBSD committer: [EMAIL PROTECTED] ] -------- *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- [EMAIL PROTECTED] *** ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
RE: Panic on ZFS startup after crash
On Sat, 19 Jul 2008, Daniel Eriksson wrote: DE> > Just a suggestion, but try specify vfs.zfs.zil_disable=1 or DE> > as a kernel variable in the boot cli. DE> DE> I just tried this and unfortunately it didn't work. I got the exact same DE> kernel panic. DE> DE> I've been looking through the code to try to find a way to fool ZFS into DE> thinking the intent log. Anyone familiar with the code that could point DE> me in the right direction? You may find useful trying to ask Pawel (pjd@) directly. I'd CC:d him to simplify process ;-) Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] [ FreeBSD committer: [EMAIL PROTECTED] ] -------- *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- [EMAIL PROTECTED] *** ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: 7-STABLE, gjournal and fsck.
On Sun, 3 Aug 2008, Eugene Butusov wrote: EB> > Did you re-create your file systems? How did you create the journal? EB> > EB> > eg. newfs /dev/ad4s1g.journal ? EB> > EB> > or did you just enable journal on the partition? via tunefs? EB> EB> I did it this way: EB> EB> /dev/ad4s1g is my /home, an existing partition EB> EB> umount /home EB> gjournal label -f /dev/ad4s1g EB> tunefs -J enable -n disable /dev/ad4s1g.journal EB> (added 'async' option to /etc/fstab for /home and changed entry to EB> /dev/ad4s1g.journal) EB> mount /home EB> EB> It worked until power failed... :) No surprize. with you `gjournal label' command you've effectively destroyed last 1G of UFS. You should use external journal provider in such case. Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] [ FreeBSD committer: [EMAIL PROTECTED] ] ---- *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- [EMAIL PROTECTED] *** ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Intel D2500cc video problem: no scrolling
Dear colleagues, in the process of upgrading my home router I'm trying to utilise Intel D2500CC mini-ITX motherboard[1]. Both stable/9 and head suffer from no scrolling issue: from the beginning of booting the kernel, all output overrides the last line on the screen, while others keep the loader phase. Provided the board has multiple serial ports and the final target (headless machine), I suppose it is not too big problem to finish install, but it would be great the issue to be fixed ;) Any hints? [1]: http://ark.intel.com/products/56462/Intel-Desktop-Board-D2500CC -- Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] [ FreeBSD committer: ma...@freebsd.org ] *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- ma...@rinet.ru *** ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Intel D2500cc video problem: no scrolling
On Mon, 23 Jul 2012, Frank Reppin wrote: > > Both stable/9 and head suffer from no scrolling issue: from the beginning of > > booting the kernel, all output overrides the last line on the screen, while > > others keep the loader phase. > just catched up with older mails on -current... > ... it looks like PHK has already committed a fix > into current: > > http://svnweb.freebsd.org/base/head/sys/dev/fb/fbreg.h?view=log&pathrev=237223 Thanks a lot! Somehow google results does not show this even when phk has exactly the same mobo... I'll try contemporary -current tomorrow. -- Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] [ FreeBSD committer: ma...@freebsd.org ] -------- *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- ma...@rinet.ru *** ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
