Re: [r222277] Strange GEOM, bsdlabel and ZFS behavior
On 9 June 2011 10:45, Eir Nym wrote: > On 8 June 2011 23:12, Vladislav V. Prodan wrote: >> 08.06.2011 17:54, Eir Nym wrote: >>> >>> On 8 June 2011 16:10, Vladislav V. Prodan wrote: 08.06.2011 11:10, Eir Nym wrote: > > gpart show is work now, but not when I load zfs into memory and try to > add zpool into. > > and when I'll boot gpart says 'GEOM: ada0s1a invalid disklabel' Output: gpart show ada0 >>> #gpart show ada0 >>> => 63 1250263665 ada0 MBR (596G) >>> 63 411807627 1 freebsd (196G) >>> 411807690 54 - free - (27k) >>> 411807744 202752 2 !239 (99M) >>> 412010496 204800 3 ntfs [active] (100M) >>> 412215296 838045696 4 ntfs (399G) >>> 1250260992 2736 - free - (1.3M) >>> #gpart show ada0s1 >>> => 0 411807627 ada0s1 BSD (196G) >>> 0 402653247 1 freebsd-zfs (192G) >>> 402653247 9154380 2 freebsd-swap (4.4G) >>> >> >> gpart modify -i 1 -l disk0 ada0s1 > gpart: Invalid argument > > after recreate ada0s1 there gpart shows 4 GEOMs with BSD partitioning > (numbers are same as above): > ada0s1 > ada0s1 > ada0s1c > ada0s1c > > > -- > If I create BSD scheme with old good bsdlabel(8): (numbers are written > by hands to minimize reboot count) > #gpart delete -i 1 ada0s1 > #gpart delete -i 2 ada0s1 > #gpart destroy ada0s1 > #bsdlabel -w ada0s1 > #gpart show ada0s1 > => 0 411807627 ada0s1 BSD (196G) > 0 16 -free - (8.0k) ---> used by > BSDLabel data > 16 411807611 1 !0 (196G) ---> ada0s1a > > and this label is correct. > > I think that GEOM part create and add commands must add some gap > before partitions for any schemes and bug is here. > http://www.freebsd.org/cgi/query-pr.cgi?pr=157723 http://www.freebsd.org/cgi/query-pr.cgi?pr=157724 >> and after reboot try: >> zpool create tank /dev/gpt/disk0 >> >> > > >> >> >> -- >> Vladislav V. Prodan >> VVP24-UANIC >> +380[67]4584408 >> +380[99]4060508 >> vla...@jabber.ru >> ___ >> freebsd-current@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-current >> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" >> > ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [r222277] Strange GEOM, bsdlabel and ZFS behavior
On 09.06.2011 11:31, Eir Nym wrote: > http://www.freebsd.org/cgi/query-pr.cgi?pr=157723 Can't reproduce. > http://www.freebsd.org/cgi/query-pr.cgi?pr=157724 First of read this tread: http://lists.freebsd.org/pipermail/freebsd-stable/2011-May/062744.html >>> and after reboot try: >>> zpool create tank /dev/gpt/disk0 -- WBR, Andrey V. Elsukov signature.asc Description: OpenPGP digital signature
Re: [r222277] Strange GEOM, bsdlabel and ZFS behavior
2011/6/9 Andrey V. Elsukov : > On 09.06.2011 11:31, Eir Nym wrote: >> http://www.freebsd.org/cgi/query-pr.cgi?pr=157723 > > Can't reproduce. Which revision do you use? Following link for mail is about this. > >> http://www.freebsd.org/cgi/query-pr.cgi?pr=157724 > > First of read this tread: > http://lists.freebsd.org/pipermail/freebsd-stable/2011-May/062744.html > and after reboot try: zpool create tank /dev/gpt/disk0 > > > -- > WBR, Andrey V. Elsukov > > I've already compilled r222889 and will check it today. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [r222277] Strange GEOM, bsdlabel and ZFS behavior
On 09.06.2011 13:32, Eir Nym wrote: > Which revision do you use? > > Following link for mail is about this. >>> http://www.freebsd.org/cgi/query-pr.cgi?pr=157724 >> >> First of read this tread: >> http://lists.freebsd.org/pipermail/freebsd-stable/2011-May/062744.html I mean that BSD scheme created with gpart(8) is not invalid. You always can use "-b start_offset" when creating partitions to preserve metadata area. Also you can use partition with zero offset for UFS. > I've already compilled r222889 and will check it today. I have r222733. But it is no matter, nothing was changed in this area for 2-3 weeks. -- WBR, Andrey V. Elsukov signature.asc Description: OpenPGP digital signature
Re: [r222277] Strange GEOM, bsdlabel and ZFS behavior
2011/6/9 Andrey V. Elsukov : > On 09.06.2011 13:32, Eir Nym wrote: >> Which revision do you use? >> >> Following link for mail is about this. http://www.freebsd.org/cgi/query-pr.cgi?pr=157724 >>> >>> First of read this tread: >>> http://lists.freebsd.org/pipermail/freebsd-stable/2011-May/062744.html > > I mean that BSD scheme created with gpart(8) is not invalid. > You always can use "-b start_offset" when creating partitions to preserve > metadata area. Also you can use partition with zero offset for UFS. > >> I've already compilled r222889 and will check it today. > > I have r222733. But it is no matter, nothing was changed in this area > for 2-3 weeks. > GEOM will say it only after reboot. part of dmesg log: GEOM_LABEL[1]: MSDOSFS: gzero: no FAT signature found. ugen0.1: at usbus0 uhub0: on usbus0 ugen1.1: at usbus1 uhub1: on usbus1 ugen2.1: at usbus2 uhub2: on usbus2 ugen3.1: at usbus3 uhub3: on usbus3 ugen4.1: at usbus4 uhub4: on usbus4 GEOM_LABEL[1]: MSDOSFS: gzero: no FAT signature found. 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: 610480MB (1250263728 512 byte sectors: 16H 63S/T 16383C) ada0: Previously was known as ad4 SMP: AP CPU #1 Launched! Timecounter "TSC" frequency 1666519680 Hz quality 800 uhub0: 2 ports with 2 removable, self powered uhub1: 2 ports with 2 removable, self powered uhub2: 2 ports with 2 removable, self powered uhub3: 2 ports with 2 removable, self powered GEOM_LABEL[1]: MSDOSFS: ada0: FAT12/16 volume not valid. GEOM_LABEL[1]: MSDOSFS: ada0s1: no FAT signature found. GEOM_LABEL[1]: MSDOSFS: ada0s2: no FAT signature found. GEOM_LABEL[1]: MSDOSFS: ada0s3: FAT32 volume not valid. GEOM_LABEL[1]: Label for provider ada0s3 is ntfs/System Reserved. GEOM_LABEL[1]: MSDOSFS: ada0s4: FAT32 volume not valid. GEOM_LABEL[1]: MSDOSFS: ada0s1: no FAT signature found. g_dev_taste: make_dev_p() failed (gp->name=ada0s1, error=17) GEOM_LABEL[1]: MSDOSFS: ada0s2: no FAT signature found. g_dev_taste: make_dev_p() failed (gp->name=ada0s2, error=17) GEOM_LABEL[1]: MSDOSFS: ada0s3: FAT32 volume not valid. GEOM_LABEL[1]: Label System Reserved(ntfs/System Reserved) already exists (ada0s3). g_dev_taste: make_dev_p() failed (gp->name=ada0s3, error=17) GEOM_LABEL[1]: MSDOSFS: ada0s4: FAT32 volume not valid. g_dev_taste: make_dev_p() failed (gp->name=ada0s4, error=17) GEOM_LABEL[1]: MSDOSFS: ada0s1a: no FAT signature found. GEOM: ada0s1a: invalid disklabel. GEOM_LABEL[1]: MSDOSFS: ada0s1b: no FAT signature found. GEOM_LABEL[1]: MSDOSFS: ada0s1c: no FAT signature found. GEOM_LABEL[1]: MSDOSFS: ada0s1a: no FAT signature found. g_dev_taste: make_dev_p() failed (gp->name=ada0s1a, error=17) GEOM_LABEL[1]: MSDOSFS: ada0s1b: no FAT signature found. g_dev_taste: make_dev_p() failed (gp->name=ada0s1b, error=17) GEOM_LABEL[1]: MSDOSFS: ada0s1a: no FAT signature found. GEOM: ada0s1a: invalid disklabel. g_dev_taste: make_dev_p() failed (gp->name=ada0s1a, error=17) GEOM_LABEL[1]: MSDOSFS: ada0s1b: no FAT signature found. g_dev_taste: make_dev_p() failed (gp->name=ada0s1b, error=17) GEOM_LABEL[1]: MSDOSFS: ada0s1c: no FAT signature found. g_dev_taste: make_dev_p() failed (gp->name=ada0s1c, error=17) GEOM_LABEL[1]: MSDOSFS: ada0s1a: no FAT signature found. g_dev_taste: make_dev_p() failed (gp->name=ada0s1a, error=17) GEOM_LABEL[1]: MSDOSFS: ada0s1b: no FAT signature found. g_dev_taste: make_dev_p() failed (gp->name=ada0s1b, error=17) GEOM_LABEL[1]: MSDOSFS: ada0s1ca: no FAT signature found. GEOM_LABEL[1]: MSDOSFS: ada0s1cb: no FAT signature found. GEOM_LABEL[1]: MSDOSFS: ada0s1aa: no FAT signature found. GEOM_LABEL[1]: MSDOSFS: ada0s1ab: no FAT signature found. GEOM_LABEL[1]: MSDOSFS: ada0s1ac: no FAT signature found. GEOM_LABEL[1]: MSDOSFS: ada0s1ca: no FAT signature found. g_dev_taste: make_dev_p() failed (gp->name=ada0s1ca, error=17) GEOM_LABEL[1]: MSDOSFS: ada0s1cb: no FAT signature found. g_dev_taste: make_dev_p() failed (gp->name=ada0s1cb, error=17) GEOM_LABEL[1]: MSDOSFS: ada0s1aa: no FAT signature found. g_dev_taste: make_dev_p() failed (gp->name=ada0s1aa, error=17) GEOM_LABEL[1]: MSDOSFS: ada0s1ab: no FAT signature found. g_dev_taste: make_dev_p() failed (gp->name=ada0s1ab, error=17) GEOM_LABEL[1]: MSDOSFS: ada0s1ac: no FAT signature found. g_dev_taste: make_dev_p() failed (gp->name=ada0s1ac, error=17) > -- > WBR, Andrey V. Elsukov > > ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re[2]: 2 day GENERIC-current eat 2 CPU core at 100%
Hi, yesterday I tried switch event timer on i8254 - it do nothing. I disabled hyperthreading - now eat from 50% to 100% All dmesg is lines: (noperiph:ata3:0:-1:-1): rescan already queued (noperiph:ata3:0:-1:-1): rescan already queued (noperiph:ata2:0:-1:-1): rescan already queued (noperiph:ata3:0:-1:-1): rescan already queued (noperiph:ata3:0:-1:-1): rescan already queued I boot FreeBSD from USB with no ATA - may be it is. %sysctl -a | grep event kern.eventtimer.choice: HPET(450) HPET1(440) HPET2(440) LAPIC(400) i8254(100) RTC(0) kern.eventtimer.et.LAPIC.flags: 15 kern.eventtimer.et.LAPIC.frequency: 0 kern.eventtimer.et.LAPIC.quality: 400 kern.eventtimer.et.HPET.flags: 3 kern.eventtimer.et.HPET.frequency: 14318180 kern.eventtimer.et.HPET.quality: 450 kern.eventtimer.et.HPET1.flags: 3 kern.eventtimer.et.HPET1.frequency: 14318180 kern.eventtimer.et.HPET1.quality: 440 kern.eventtimer.et.HPET2.flags: 3 kern.eventtimer.et.HPET2.frequency: 14318180 kern.eventtimer.et.HPET2.quality: 440 kern.eventtimer.et.RTC.flags: 17 kern.eventtimer.et.RTC.frequency: 32768 kern.eventtimer.et.RTC.quality: 0 kern.eventtimer.et.i8254.flags: 1 kern.eventtimer.et.i8254.frequency: 1193182 kern.eventtimer.et.i8254.quality: 100 kern.eventtimer.periodic: 1 kern.eventtimer.timer: i8254 kern.eventtimer.idletick: 0 kern.eventtimer.singlemul: 2 "ifnet_rw","eventhandler" "eventhandler","eventhandler list" "so_rcv","eventhandler" "lle","eventhandler" "Giant","intr event list" "Giant","eventhandler" "Giant","eventhandler list" "Giant","intr event" "proctree","clone events drain lock" "clone events drain lock","cdev" "clone events drain lock","eventhandler" "clone events drain lock","eventhandler list" "devfs","clone events drain lock" "MD config lock","eventhandler" hw.mfi.event_class: 0 hw.mfi.event_locale: 65535 CL\PU load is waves with period about 20sec. _ %systat -vmstat 2 usersLoad 3,47 2,85 2,80 9 июн 14:45 Mem:KBREALVIRTUAL VN PAGER SWAP PAGER Tot Share TotShareFree in out in out Act 166963772 285868 5120 51636 count All 942045096 244978822376 pages Proc:Interrupts r p d s w Csw Trp Sys Int Sof Fltcow2018 total 29 1371 25 2018 673 zfodatkbd0 1 ozfod 1998 attimer0 0 50,2%Sys 0,9%Intr 0,1%User 0,0%Nice 48,7%Idle%ozfod hpet0 20 ||||||||||| daefr 1 uhci0 ehci =+prcfr19 re0 256 2 dtbuf totfr Namei Name-cache Dir-cache 68416 desvn react Callshits %hits % 58261 numvn pdwak 3 3 100 17084 frevn pdpgs intrn Disks md8 da0 pass0121076 wire KB/t 0,00 2,00 0,00 32224 act tps 0 0 0790704 inact MB/s 0,00 0,00 0,00 9560 cache %busy 0 0 0 42076 free After half minute ___ 2 usersLoad 3,52 2,90 2,81 9 июн 14:46 Mem:KBREALVIRTUAL VN PAGER SWAP PAGER Tot Share TotShareFree in out in out Act 166963772 285868 5120 51636 count All 942045096 244978822376 pages Proc:Interrupts r p d s w Csw Trp Sys Int Sof Fltcow2022 total 5 24801 18 2023 803 zfodatkbd0 1 ozfod 2000 attimer0 0 57,8%Sys 26,0%Intr 0,0%User 0,0%Nice 16,2%Idle%ozfod hpet0 20 ||||||||||| daefr uhci0 ehci =+prcfr22 re0 256 dtbuf totfr Namei Name-cache Dir-cache 68416 desvn react Callshits %hits % 58261 numvn pdwak 3 3 100 17084 frevn pdpgs intrn Disks md8 da0 pass0121076 wire KB/t 0,00 0,00 0,00 32228 act tps 0 0 079
Re: NEW_PCIB? pcib1: failed to allocate initial I/O port window: 0x4000-0x4fff
On Thursday, June 09, 2011 2:11:16 am Andriy Gapon wrote: > on 09/06/2011 01:30 John said the following: > > Sorry John, here's the verbose dmesg output with your patch applied. > > > > This is at the tail of the console: > > > > pcib1: allocated memory range (0xf600-0xf6ff) for rid 10 of > > pci0:1:3:0 > > map[14]: type I/O Port, range 32, base 0x4400, size 8, enabled > > pcib1: failed to allocate initial I/O port window (0x4000-0x4fff,0x1000) > > map[18]: type Memory, range 32, base 0xf5ff, size 12, enabled > > > > > > Output ends with a single 'M', not MCA as earlier. > > > Just a wild guess - what happens if you revert r222537 (you might need to > revert > r222804 first)? I think he's getting a MCA due to writing to a bad address and getting a PCI-e target abort equivalent and that the screen output is broken because the VGA device is what is probably getting hosed by the pcib driver. Given that, I doubt the printf changes are related. -- John Baldwin ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: any place to look at for PCI-express performance issues ?
On Wednesday, June 08, 2011 11:59:52 pm Luigi Rizzo wrote: > hi, > during my tests with netmap with 10Gbit cards (82599, dual port), > i notice that a motherboard with an AMD 880G chipset > is performing significantly worse than an intel based one. > In both cases the NIC is mounted on a 16x PCIe slot, > and in both cases the driver reports the use 5Gb/4x per port. > > On the intel i reach easily 14.88Mpps, on the AMD the card tops > at 1.8Mpps, and is not CPU limited (changing dev.cpu.0.freq does not change > the throughput). > Disabling flow control does not help (and in any case > the other end of the link is the same), and since > I am using the same picobsd image (based on FreeBSD/i386 > head w/ my netmap code) i suspect that the difference in > performance has to do with the PCIe controller. > My netmap code > http://info.iet.unipi.it/~luigi/netmap/ > does nothing special on the bus. > > Now, the question is, is there any place in FreeBSD sources that > might be related to PCIe performance, e.g. initialising specific > features in one or another northbridge, etc ? No, in general we rely on the firmware (BIOS, etc.) to configure those bits. You might take a gander at comparing 'pciconf -lc' output as that displays a few of the PCI-e settings such as the actual number of lanes used, etc. -- John Baldwin ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: pcib allocation failure
On Wednesday, June 08, 2011 4:20:00 pm deeptec...@gmail.com wrote:
> On Wed, Jun 8, 2011 at 7:56 PM, John Baldwin wrote:
> > On Wednesday, June 08, 2011 11:20:17 am deeptec...@gmail.com wrote:
> >> On Tue, Jun 7, 2011 at 4:35 PM, John Baldwin wrote:
> >> found-> vendor=0x1002, dev=0x4170, revid=0x00
> >> domain=0, bus=1, slot=0, func=1
> >> class=03-80-00, hdrtype=0x00, mfdev=0
> >> cmdreg=0x0007, statreg=0x02b0, cachelnsz=4 (dwords)
> >> lattimer=0x40 (1920 ns), mingnt=0x08 (2000 ns), maxlat=0x00 (0 ns)
> >> powerspec 2 supports D0 D1 D2 D3 current D0
> >> map[10]: type Prefetchable Memory, range 32, base 0xe000, size
> >> 28, enabled
> >> pcib1: attempting to grow prefetch window for
> >> (0xe000-0xefff,0x1000)
> >> pcib1: attempting to grow memory window for
> >> (0xe000-0xefff,0x1000)
> >
> > Odd, I'm not sure why this failed. Hmm, it seems this was always failing
> > for
> > you though in the older dmesg's though.
> >
> > Hmmm, can you revert all your changes to pci_pci.c and try just this change:
> >
> > Index: pci_pci.c
> > ===
> > --- pci_pci.c (revision 222863)
> > +++ pci_pci.c (working copy)
> > @@ -953,7 +975,7 @@ pcib_grow_window(struct pcib_softc *sc, struct pci
> > * ok, ensure it is properly aligned for this window.
> > * Also check for overflow.
> > */
> > - if (back <= end && start_free <= back) {
> > + if (back <= end + 1 && start_free <= back) {
> >if (bootverbose)
> >printf("\tback candidate range: %#lx-%#lx\n",
> >start_free, back);
>
> failure.
Hmm, I would say 'progress' actually as it's getting better:
> map[10]: type Prefetchable Memory, range 32, base 0xe000, size 28,
> enabled
> pcib1: attempting to grow prefetch window for
> (0xe000-0xefff,0x1000)
> back candidate range: 0xe000-0xf000
It at least attempts to grow it now.
This patch is a slightly more correct fix for the same bug as above but also
adds extra debugging so I can see why bus_adjust_resource() is failing to
grow the window. It won't fix it yet, but should output more debug info
when it fails to grow the window:
Index: pci_pci.c
===
--- pci_pci.c (revision 222863)
+++ pci_pci.c (working copy)
@@ -916,7 +934,8 @@ pcib_grow_window(struct pcib_softc *sc, struct pci
/* Move end_free down until it is properly aligned. */
end_free &= ~(align - 1);
- front = end_free - count;
+ end_free--;
+ front = end_free - (count - 1);
/*
* The resource would now be allocated at (front,
@@ -944,7 +963,7 @@ pcib_grow_window(struct pcib_softc *sc, struct pci
/* Move start_free up until it is properly aligned. */
start_free = roundup2(start_free, align);
- back = start_free + count;
+ back = start_free + count - 1;
/*
* The resource would now be allocated at (start_free,
@@ -957,7 +976,7 @@ pcib_grow_window(struct pcib_softc *sc, struct pci
if (bootverbose)
printf("\tback candidate range: %#lx-%#lx\n",
start_free, back);
- back = roundup2(back, w->step) - 1;
+ back = roundup2(back + 1, w->step) - 1;
back -= rman_get_end(w->res);
} else
back = 0;
@@ -976,6 +995,11 @@ pcib_grow_window(struct pcib_softc *sc, struct pci
rman_get_end(w->res));
if (error == 0)
break;
+ if (bootverbose)
+ device_printf(sc->dev,
+ "failed to grow %s window to %#lx-%#lx: %d\n",
+ w->name, rman_get_start(w->res) - front,
+ rman_get_end(w->res), error);
front = 0;
} else {
error = bus_adjust_resource(sc->dev, type, w->res,
@@ -983,6 +1007,11 @@ pcib_grow_window(struct pcib_softc *sc, struct pci
rman_get_end(w->res) + back);
if (error == 0)
break;
+ if (bootverbose)
+ device_printf(sc->dev,
+ "failed to grow %s window to %#lx-%#lx: %d\n",
+ w->name, rman_get_start(w->res),
+ rman_get_end(w->res) + back, error);
Re: 2 day GENERIC-current eat 2 CPU core at 100%
Andrey Smagin wrote: > Hi, yesterday I tried switch event timer on i8254 - it do nothing. > I disabled hyperthreading - now eat from 50% to 100% > All dmesg is lines: > (noperiph:ata3:0:-1:-1): rescan already queued > (noperiph:ata3:0:-1:-1): rescan already queued > (noperiph:ata2:0:-1:-1): rescan already queued > (noperiph:ata3:0:-1:-1): rescan already queued > (noperiph:ata3:0:-1:-1): rescan already queued > > I boot FreeBSD from USB with no ATA - may be it is. These messages are not what I expected to see, but they tell me that your problem may be SATA related. I've got the same Intel D525MW board and think reproduced the problem. I hope I've even fixed it. :) Retry please with fresh CURRENT sources or at least with this patch applied: http://svn.freebsd.org/changeset/base/222897 > Wed, 08 Jun 2011 20:34:42 +0300 письмо от Alexander Motin : >> On 07.06.2011 20:12, Andrey Smagin wrote: >>> vmstat -i >>> interrupt total rate >>> irq16: uhci3 205 0 >>> irq20: hpet0 147924380 1126 >>> irq23: uhci0 ehci0 522517 3 >>> total148447102 1130 >>> >>> Tue, 7 Jun 2011 10:34:01 +0200 письмо от Hans Petter >> Selasky: On Tuesday 07 June 2011 10:09:47 Andrey Smagin wrote: > I upgraded 2 day ago from 2010-current box on Intel D525MW. > System very slow down after that. > kern.hz=50 > in systat -vmstat - 140hpet interrupts/s > at top 25% in interrupts 25% in system > because hyperthreading system found 4 cpu. What does vmstat -i output? >> Send me please full verbose dmesg and output of the `sysctl >> kern.eventtimer` and `sysctl kern.timecounter`. >> >> Try to switch to another timer: >> sysctl kern.eventtimer.timer=LAPIC >> >> Try to switch to periodic timers (instead): >> sysctl kern.eventtimer.periodic=1 -- Alexander Motin ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
gcc-4.5 and 4.6 needs to be recompiled due to /usr/src/UPDATE: 20110608:
Since the notice mentioned in /usr/src/UPDATE (20110608) both gcc-4.5 and 4.6 seems to need to be recompiled. I tried some ports with "USE_FORTRAN= yes" setand they failed as with gcc-4.6. There was always an error reporting: undefined reference to __cpumask_t or similar. Oliver ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: pcib allocation failure
On Thu, Jun 9, 2011 at 3:22 PM, John Baldwin wrote:
> Hmm, I would say 'progress' actually as it's getting better:
>
>
>> map[10]: type Prefetchable Memory, range 32, base 0xe000, size 28,
>> enabled
>> pcib1: attempting to grow prefetch window for
>> (0xe000-0xefff,0x1000)
>> back candidate range: 0xe000-0xf000
>
> It at least attempts to grow it now.
>
> This patch is a slightly more correct fix for the same bug as above but also
> adds extra debugging so I can see why bus_adjust_resource() is failing to
> grow the window. It won't fix it yet, but should output more debug info
> when it fails to grow the window:
see PS.
> Index: pci_pci.c
> ===
> --- pci_pci.c (revision 222863)
> +++ pci_pci.c (working copy)
> @@ -916,7 +934,8 @@ pcib_grow_window(struct pcib_softc *sc, struct pci
>
> /* Move end_free down until it is properly aligned. */
> end_free &= ~(align - 1);
> - front = end_free - count;
> + end_free--;
> + front = end_free - (count - 1);
>
> /*
> * The resource would now be allocated at (front,
> @@ -944,7 +963,7 @@ pcib_grow_window(struct pcib_softc *sc, struct pci
>
> /* Move start_free up until it is properly aligned. */
> start_free = roundup2(start_free, align);
> - back = start_free + count;
> + back = start_free + count - 1;
>
> /*
> * The resource would now be allocated at (start_free,
> @@ -957,7 +976,7 @@ pcib_grow_window(struct pcib_softc *sc, struct pci
> if (bootverbose)
> printf("\tback candidate range: %#lx-%#lx\n",
> start_free, back);
> - back = roundup2(back, w->step) - 1;
> + back = roundup2(back + 1, w->step) - 1;
> back -= rman_get_end(w->res);
> } else
> back = 0;
> @@ -976,6 +995,11 @@ pcib_grow_window(struct pcib_softc *sc, struct pci
> rman_get_end(w->res));
> if (error == 0)
> break;
> + if (bootverbose)
> + device_printf(sc->dev,
> + "failed to grow %s window to %#lx-%#lx: %d\n",
> + w->name, rman_get_start(w->res) - front,
> + rman_get_end(w->res), error);
> front = 0;
> } else {
> error = bus_adjust_resource(sc->dev, type, w->res,
> @@ -983,6 +1007,11 @@ pcib_grow_window(struct pcib_softc *sc, struct pci
> rman_get_end(w->res) + back);
> if (error == 0)
> break;
> + if (bootverbose)
> + device_printf(sc->dev,
> + "failed to grow %s window to %#lx-%#lx: %d\n",
> + w->name, rman_get_start(w->res),
> + rman_get_end(w->res) + back, error);
> back = 0;
> }
> }
== dmesg begins ==
Copyright (c) 1992-2011 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
The Regents of the University of California. All rights reserved.
FreeBSD is a registered trademark of The FreeBSD Foundation.
FreeBSD 9.0-CURRENT #0 r222709M: Sun Jun 5 20:01:55 CEST 2011
devhc@:/usr/obj/usr/src/sys/HQ i386
CPU: Intel(R) Pentium(R) 4 CPU 2.80GHz (2798.72-MHz 686-class CPU)
Origin = "GenuineIntel" Id = 0xf29 Family = f Model = 2 Stepping = 9
Features=0xbfebfbff
Features2=0x4400
real memory = 536870912 (512 MB)
avail memory = 513818624 (490 MB)
Event timer "LAPIC" quality 400
ACPI APIC Table:
FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs
FreeBSD/SMP: 2 package(s) x 1 core(s)
cpu0 (BSP): APIC ID: 0
cpu1 (AP): APIC ID: 1
ioapic0 irqs 0-23 on motherboard
kbd1 at kbdmux0
acpi0: on motherboard
acpi0: Power Button (fixed)
acpi0: reservation of 0, a (3) failed
acpi0: reservation of 10, 1fef (3) failed
Timecounter "ACPI-fast" frequency 3579545 Hz quality 900
acpi_timer0: <24-bit timer at 3.579545MHz> port 0x808-0x80b on acpi0
cpu0: on acpi0
cpu1: on acpi0
pcib0: port 0xcf8-0xcff on acpi0
pci0: on pcib0
agp0: on hostb0
pcib1: at device 1.0 on pci0
pci1: on pcib1
vgapci0: port 0xd000-0xd0ff mem
0xd000-0xdfff,0xf7ee-0xf7ee irq 16 at device 0.0 on
pci1
drm0: on vgapci0
info: [drm] AGP at 0xf800 64MB
info: [drm] Initialized radeon 1.31.0 20080613
vgapci1: mem
0xe000-0xefff,0xf7ef-0xf7ef at device 0.1 on pci1
uhci0: port 0xc880-0xc89
Re: gcc-4.5 and 4.6 needs to be recompiled due to /usr/src/UPDATE: 20110608:
2011/6/9 Hartmann, O. : > Since the notice mentioned in /usr/src/UPDATE (20110608) both gcc-4.5 and > 4.6 seems to need to be recompiled. I tried some ports with "USE_FORTRAN= > yes" setand they failed as with gcc-4.6. There was always an error > reporting: undefined reference to __cpumask_t or similar. > Yes, this fix broke ABI. I still didn't bump __FreeBSD_version because I have more changes coming that will change the KBI, thus I just wanted to do that at the end of the process. If ports@ need the __FreeBSD_version bumped right now, please just let me know. Attilio -- Peace can only be achieved by understanding - A. Einstein ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: pcib allocation failure
On Thursday, June 09, 2011 2:07:31 pm deeptec...@gmail.com wrote:
> pcib1: attempting to grow prefetch window for
> (0xe000-0xefff,0x1000)
> back candidate range: 0xe000-0xefff
> pcib1: failed to grow prefetch window to 0xd000-0xefff: 6
Hmm, ENXIO is an odd error. rman_adjust_resource() can't fail with that.
Oh, I missed adding bus_adjust_resource() to the x86 "nexus" drivers. :(
Try this patch in addition to the patch to pci_pci.c that you are already using:
Index: amd64/amd64/legacy.c
===
--- amd64/amd64/legacy.c(revision 222897)
+++ amd64/amd64/legacy.c(working copy)
@@ -81,6 +81,7 @@
DEVMETHOD(bus_read_ivar,legacy_read_ivar),
DEVMETHOD(bus_write_ivar, legacy_write_ivar),
DEVMETHOD(bus_alloc_resource, bus_generic_alloc_resource),
+ DEVMETHOD(bus_adjust_resource, bus_generic_adjust_resource),
DEVMETHOD(bus_release_resource, bus_generic_release_resource),
DEVMETHOD(bus_activate_resource, bus_generic_activate_resource),
DEVMETHOD(bus_deactivate_resource, bus_generic_deactivate_resource),
Index: dev/acpica/acpi.c
===
--- dev/acpica/acpi.c (revision 222897)
+++ dev/acpica/acpi.c (working copy)
@@ -123,6 +123,8 @@
static struct resource *acpi_alloc_resource(device_t bus, device_t child,
int type, int *rid, u_long start, u_long end,
u_long count, u_int flags);
+static int acpi_adjust_resource(device_t bus, device_t child, int type,
+ struct resource *r, u_long start, u_long end);
static int acpi_release_resource(device_t bus, device_t child, int type,
int rid, struct resource *r);
static voidacpi_delete_resource(device_t bus, device_t child, int type,
@@ -193,6 +195,7 @@
DEVMETHOD(bus_set_resource,acpi_set_resource),
DEVMETHOD(bus_get_resource,bus_generic_rl_get_resource),
DEVMETHOD(bus_alloc_resource, acpi_alloc_resource),
+DEVMETHOD(bus_adjust_resource, acpi_adjust_resource),
DEVMETHOD(bus_release_resource,acpi_release_resource),
DEVMETHOD(bus_delete_resource, acpi_delete_resource),
DEVMETHOD(bus_child_pnpinfo_str, acpi_child_pnpinfo_str_method),
@@ -1325,29 +1328,40 @@
}
static int
-acpi_release_resource(device_t bus, device_t child, int type, int rid,
-struct resource *r)
+acpi_is_resource_managed(int type, struct resource *r)
{
-struct rman *rm;
-int ret;
/* We only handle memory and IO resources through rman. */
switch (type) {
case SYS_RES_IOPORT:
- rm = &acpi_rman_io;
- break;
+ return (rman_is_region_manager(r, &acpi_rman_io));
case SYS_RES_MEMORY:
- rm = &acpi_rman_mem;
- break;
-default:
- rm = NULL;
+ return (rman_is_region_manager(r, &acpi_rman_mem));
}
+return (0);
+}
+static int
+acpi_adjust_resource(device_t bus, device_t child, int type, struct resource
*r,
+u_long start, u_long end)
+{
+
+if (acpi_is_resource_managed(type, r))
+ return (rman_adjust_resource(r, start, end));
+return (bus_generic_adjust_resource(bus, child, type, r, start, end));
+}
+
+static int
+acpi_release_resource(device_t bus, device_t child, int type, int rid,
+struct resource *r)
+{
+int ret;
+
/*
* If this resource belongs to one of our internal managers,
* deactivate it and release it to the local pool.
*/
-if (rm != NULL && rman_is_region_manager(r, rm)) {
+if (acpi_is_resource_managed(type, r)) {
if (rman_get_flags(r) & RF_ACTIVE) {
ret = bus_deactivate_resource(child, type, rid, r);
if (ret != 0)
Index: i386/i386/legacy.c
===
--- i386/i386/legacy.c (revision 222897)
+++ i386/i386/legacy.c (working copy)
@@ -86,6 +86,7 @@
DEVMETHOD(bus_read_ivar,legacy_read_ivar),
DEVMETHOD(bus_write_ivar, legacy_write_ivar),
DEVMETHOD(bus_alloc_resource, bus_generic_alloc_resource),
+ DEVMETHOD(bus_adjust_resource, bus_generic_adjust_resource),
DEVMETHOD(bus_release_resource, bus_generic_release_resource),
DEVMETHOD(bus_activate_resource, bus_generic_activate_resource),
DEVMETHOD(bus_deactivate_resource, bus_generic_deactivate_resource),
--
John Baldwin
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: gcc-4.5 and 4.6 needs to be recompiled due to /usr/src/UPDATE: 20110608:
On Thu, Jun 09, 2011 at 08:07:15PM +0200, Hartmann, O. wrote: > Since the notice mentioned in /usr/src/UPDATE (20110608) both gcc-4.5 > and 4.6 seems to need to be recompiled. I tried some ports with > "USE_FORTRAN= yes" setand they failed as with gcc-4.6. There was always > an error reporting: undefined reference to __cpumask_t or similar. There is a huge problem somewhere. It is either in the commit, that broke the userspace ABI, but it is not much likely, or there is a problem in you configuration. Anyway, there is another big issue, in your report, that contains no useful information, and could be classified as FUD. pgpxpnPccrXZa.pgp Description: PGP signature
Re: pcib allocation failure
On Jun 9, 2011, at 11:07 AM, deeptec...@gmail.com wrote:
[ ... ]
> PS: u should learn to properly use backward references ("it") in ur sentences.
Hmm.
Let's just say that there are more effective ways to persuade someone like John
who is volunteering their time writing patches to continue to try and help you.
Perhaps you were trying to be ironic by discussing someone else's grammar with
such a construct? :-/
--
-Chuck
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: gcc-4.5 and 4.6 needs to be recompiled due to /usr/src/UPDATE: 20110608:
On 06/09/11 14:12, Attilio Rao wrote: > 2011/6/9 Hartmann, O. : >> Since the notice mentioned in /usr/src/UPDATE (20110608) both gcc-4.5 and >> 4.6 seems to need to be recompiled. I tried some ports with "USE_FORTRAN= >> yes" setand they failed as with gcc-4.6. There was always an error >> reporting: undefined reference to __cpumask_t or similar. >> > > Yes, this fix broke ABI. > I still didn't bump __FreeBSD_version because I have more changes > coming that will change the KBI, thus I just wanted to do that at the > end of the process. > > If ports@ need the __FreeBSD_version bumped right now, please just let me > know. This broke a number of things .. multimedia/mjpegtools, emulators/virtualbox-kmod among the ones I've tripped over so far, imb ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
FreeBSD extended to Arab World
Hi Community, First I introduce myself, Mohammed Farrag, ArabBSD Project Manager and FreeBSD Contributor. We have a project to extend FreeBSD in Arab world. We aim to work in two direction. First, we will translate FreeBSD Documentation and learning tutorials to Arabic. Second, we will have summer training for starting work on FreeBSD development. Our website is https://sites.google.com/site/arabbsd/ and our facebook group is http://www.facebook.com/home.php?sk=group_114438501975285&ap=1 I will be glad to receive your comments/ and recommendations. Regards, -- *Mohammed Farrag* ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: gcc-4.5 and 4.6 needs to be recompiled due to /usr/src/UPDATE: 20110608:
2011/6/9 Michael Butler : > On 06/09/11 14:12, Attilio Rao wrote: >> 2011/6/9 Hartmann, O. : >>> Since the notice mentioned in /usr/src/UPDATE (20110608) both gcc-4.5 and >>> 4.6 seems to need to be recompiled. I tried some ports with "USE_FORTRAN= >>> yes" setand they failed as with gcc-4.6. There was always an error >>> reporting: undefined reference to __cpumask_t or similar. >>> >> >> Yes, this fix broke ABI. >> I still didn't bump __FreeBSD_version because I have more changes >> coming that will change the KBI, thus I just wanted to do that at the >> end of the process. >> >> If ports@ need the __FreeBSD_version bumped right now, please just let me >> know. > > This broke a number of things .. multimedia/mjpegtools, > emulators/virtualbox-kmod among the ones I've tripped over so far, I think that the point I made is another: let me know if you absolutely need I bump __FreeBSD_version now, I know some ports may be broken by this change. Attilio -- Peace can only be achieved by understanding - A. Einstein ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: gcc-4.5 and 4.6 needs to be recompiled due to /usr/src/UPDATE: 20110608:
Things that change the way the base system behaves w/rt ports need version bumps. mcl ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: gcc-4.5 and 4.6 needs to be recompiled due to /usr/src/UPDATE: 20110608:
2011/6/9 Mark Linimon : > Things that change the way the base system behaves w/rt ports need > version bumps. BTW, could someone provide an actual error message? I assume these errors are caused by cpumask_t going away. Attilio -- Peace can only be achieved by understanding - A. Einstein ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: FreeBSD extended to Arab World
On 9 June 2011 22:15, Mohammed Farrag wrote: [snip: ArabBSD website] Nice initiative! Best to get the website in Arabic; IMHO works best to get members for the local community. Secondly you might want to start a mailinglist and/or forjum, as I could not find any means of communications apart from the contact form on the website. Br. /Rick -- http://rickvanderzwet.nl ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: gcc-4.5 and 4.6 needs to be recompiled due to /usr/src/UPDATE: 20110608:
On 06/09/11 17:18, Attilio Rao wrote: > 2011/6/9 Mark Linimon : >> Things that change the way the base system behaves w/rt ports need >> version bumps. > > BTW, could someone provide an actual error message? > > I assume these errors are caused by cpumask_t going away. For emulators/virtualbox-ose-kmod .. cc -O2 -pipe -march=prescott -DRT_OS_FREEBSD -DIN_RING0 -DIN_RT_R0 -DIN_SUP_R0 -DVBOX -DRT_WITH_VBOX -w -DVBOX_WITH_HARDENING -DVBOX_WITH_64_BITS_GUESTS -DRT_ARCH_X86 -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -Iinclude -I. -Ir0drv -I. -I@ -I@/contrib/altq -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-sse -mno-mmx -msoft-float -ffreestanding -fstack-protector -std=iso9899:1999 -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -c /usr/ports/emulators/virtualbox-ose-kmod/work/VirtualBox-4.0.8_OSE/out/freebsd.x86/release/bin/src/vboxdrv/r0drv/freebsd/mp-r0drv-freebsd.c /usr/ports/emulators/virtualbox-ose-kmod/work/VirtualBox-4.0.8_OSE/out/freebsd.x86/release/bin/src/vboxdrv/r0drv/freebsd/mp-r0drv-freebsd.c: In function 'RTMpOnOthers': /usr/ports/emulators/virtualbox-ose-kmod/work/VirtualBox-4.0.8_OSE/out/freebsd.x86/release/bin/src/vboxdrv/r0drv/freebsd/mp-r0drv-freebsd.c:167: error: 'cpumask_t' undeclared (first use in this function) /usr/ports/emulators/virtualbox-ose-kmod/work/VirtualBox-4.0.8_OSE/out/freebsd.x86/release/bin/src/vboxdrv/r0drv/freebsd/mp-r0drv-freebsd.c:167: error: (Each undeclared identifier is reported only once /usr/ports/emulators/virtualbox-ose-kmod/work/VirtualBox-4.0.8_OSE/out/freebsd.x86/release/bin/src/vboxdrv/r0drv/freebsd/mp-r0drv-freebsd.c:167: error: for each function it appears in.) Without a version bump, it becomes impossible to determine if a version-specific patch can be applied to accommodate the ABI change, imb ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: pcib allocation failure
On Thu, Jun 9, 2011 at 8:56 PM, John Baldwin wrote:
> On Thursday, June 09, 2011 2:07:31 pm deeptec...@gmail.com wrote:
>> pcib1: attempting to grow prefetch window for
>> (0xe000-0xefff,0x1000)
>> back candidate range: 0xe000-0xefff
>> pcib1: failed to grow prefetch window to 0xd000-0xefff: 6
>
> Hmm, ENXIO is an odd error. rman_adjust_resource() can't fail with that.
>
> Oh, I missed adding bus_adjust_resource() to the x86 "nexus" drivers. :(
>
> Try this patch in addition to the patch to pci_pci.c that you are already
> using:
>
> Index: amd64/amd64/legacy.c
> ===
> --- amd64/amd64/legacy.c (revision 222897)
> +++ amd64/amd64/legacy.c (working copy)
> @@ -81,6 +81,7 @@
> DEVMETHOD(bus_read_ivar, legacy_read_ivar),
> DEVMETHOD(bus_write_ivar, legacy_write_ivar),
> DEVMETHOD(bus_alloc_resource, bus_generic_alloc_resource),
> + DEVMETHOD(bus_adjust_resource, bus_generic_adjust_resource),
> DEVMETHOD(bus_release_resource, bus_generic_release_resource),
> DEVMETHOD(bus_activate_resource, bus_generic_activate_resource),
> DEVMETHOD(bus_deactivate_resource, bus_generic_deactivate_resource),
> Index: dev/acpica/acpi.c
> ===
> --- dev/acpica/acpi.c (revision 222897)
> +++ dev/acpica/acpi.c (working copy)
> @@ -123,6 +123,8 @@
> static struct resource *acpi_alloc_resource(device_t bus, device_t child,
> int type, int *rid, u_long start, u_long end,
> u_long count, u_int flags);
> +static int acpi_adjust_resource(device_t bus, device_t child, int type,
> + struct resource *r, u_long start, u_long end);
> static int acpi_release_resource(device_t bus, device_t child, int type,
> int rid, struct resource *r);
> static void acpi_delete_resource(device_t bus, device_t child, int type,
> @@ -193,6 +195,7 @@
> DEVMETHOD(bus_set_resource, acpi_set_resource),
> DEVMETHOD(bus_get_resource, bus_generic_rl_get_resource),
> DEVMETHOD(bus_alloc_resource, acpi_alloc_resource),
> + DEVMETHOD(bus_adjust_resource, acpi_adjust_resource),
> DEVMETHOD(bus_release_resource, acpi_release_resource),
> DEVMETHOD(bus_delete_resource, acpi_delete_resource),
> DEVMETHOD(bus_child_pnpinfo_str, acpi_child_pnpinfo_str_method),
> @@ -1325,29 +1328,40 @@
> }
>
> static int
> -acpi_release_resource(device_t bus, device_t child, int type, int rid,
> - struct resource *r)
> +acpi_is_resource_managed(int type, struct resource *r)
> {
> - struct rman *rm;
> - int ret;
>
> /* We only handle memory and IO resources through rman. */
> switch (type) {
> case SYS_RES_IOPORT:
> - rm = &acpi_rman_io;
> - break;
> + return (rman_is_region_manager(r, &acpi_rman_io));
> case SYS_RES_MEMORY:
> - rm = &acpi_rman_mem;
> - break;
> - default:
> - rm = NULL;
> + return (rman_is_region_manager(r, &acpi_rman_mem));
> }
> + return (0);
> +}
>
> +static int
> +acpi_adjust_resource(device_t bus, device_t child, int type, struct resource
> *r,
> + u_long start, u_long end)
> +{
> +
> + if (acpi_is_resource_managed(type, r))
> + return (rman_adjust_resource(r, start, end));
> + return (bus_generic_adjust_resource(bus, child, type, r, start, end));
> +}
> +
> +static int
> +acpi_release_resource(device_t bus, device_t child, int type, int rid,
> + struct resource *r)
> +{
> + int ret;
> +
> /*
> * If this resource belongs to one of our internal managers,
> * deactivate it and release it to the local pool.
> */
> - if (rm != NULL && rman_is_region_manager(r, rm)) {
> + if (acpi_is_resource_managed(type, r)) {
> if (rman_get_flags(r) & RF_ACTIVE) {
> ret = bus_deactivate_resource(child, type, rid, r);
> if (ret != 0)
> Index: i386/i386/legacy.c
> ===
> --- i386/i386/legacy.c (revision 222897)
> +++ i386/i386/legacy.c (working copy)
> @@ -86,6 +86,7 @@
> DEVMETHOD(bus_read_ivar, legacy_read_ivar),
> DEVMETHOD(bus_write_ivar, legacy_write_ivar),
> DEVMETHOD(bus_alloc_resource, bus_generic_alloc_resource),
> + DEVMETHOD(bus_adjust_resource, bus_generic_adjust_resource),
> DEVMETHOD(bus_release_resource, bus_generic_release_resource),
> DEVMETHOD(bus_activate_resource, bus_generic_activate_resource),
> DEVMETHOD(bus_deactivate_resource, bus_generic_deactivate_resource),
alright, with that patch the machine is back in business.
== dmesg begins ==
MP Configuration Table version 1.1 found at 0xc00f1280
Table 'FACP' at 0x1ff30290
Table 'APIC' at 0x1ff30390
APIC: Fo
Re: gcc-4.5 and 4.6 needs to be recompiled due to /usr/src/UPDATE: 20110608:
Hi, On Thu, Jun 9, 2011 at 6:01 PM, Michael Butler wrote: > On 06/09/11 17:18, Attilio Rao wrote: >> 2011/6/9 Mark Linimon : >>> Things that change the way the base system behaves w/rt ports need >>> version bumps. >> >> BTW, could someone provide an actual error message? >> >> I assume these errors are caused by cpumask_t going away. > > For emulators/virtualbox-ose-kmod .. > > cc -O2 -pipe -march=prescott -DRT_OS_FREEBSD -DIN_RING0 -DIN_RT_R0 > -DIN_SUP_R0 -DVBOX -DRT_WITH_VBOX -w -DVBOX_WITH_HARDENING > -DVBOX_WITH_64_BITS_GUESTS -DRT_ARCH_X86 -fno-strict-aliasing -Werror > -D_KERNEL -DKLD_MODULE -nostdinc -Iinclude -I. -Ir0drv -I. -I@ > -I@/contrib/altq -finline-limit=8000 --param inline-unit-growth=100 > --param large-function-growth=1000 -fno-common -mno-align-long-strings > -mpreferred-stack-boundary=2 -mno-sse -mno-mmx -msoft-float > -ffreestanding -fstack-protector -std=iso9899:1999 -fstack-protector > -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes > -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef > -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs > -fdiagnostics-show-option -c > /usr/ports/emulators/virtualbox-ose-kmod/work/VirtualBox-4.0.8_OSE/out/freebsd.x86/release/bin/src/vboxdrv/r0drv/freebsd/mp-r0drv-freebsd.c > > /usr/ports/emulators/virtualbox-ose-kmod/work/VirtualBox-4.0.8_OSE/out/freebsd.x86/release/bin/src/vboxdrv/r0drv/freebsd/mp-r0drv-freebsd.c: > In function 'RTMpOnOthers': > /usr/ports/emulators/virtualbox-ose-kmod/work/VirtualBox-4.0.8_OSE/out/freebsd.x86/release/bin/src/vboxdrv/r0drv/freebsd/mp-r0drv-freebsd.c:167: > error: 'cpumask_t' undeclared (first use in this function) > > /usr/ports/emulators/virtualbox-ose-kmod/work/VirtualBox-4.0.8_OSE/out/freebsd.x86/release/bin/src/vboxdrv/r0drv/freebsd/mp-r0drv-freebsd.c:167: > error: (Each undeclared identifier is reported only once > /usr/ports/emulators/virtualbox-ose-kmod/work/VirtualBox-4.0.8_OSE/out/freebsd.x86/release/bin/src/vboxdrv/r0drv/freebsd/mp-r0drv-freebsd.c:167: > error: for each function it appears in.) > > Without a version bump, it becomes impossible to determine if a > version-specific patch can be applied to accommodate the ABI change, > This sounds more an API change than an ABI change. FWIW, ABI changes that breaks backward compatibility should not happen. - Arnaud > imb > ___ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" > ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: FreeBSD extended to Arab World
Hello, Thanks for your reply. I will translate the website soon. We have already our mailing list but it's not active yet. We will activate it during the summer courses. Regards, Mohammed On Thu, Jun 9, 2011 at 11:53 PM, Rick van der Zwet wrote: > On 9 June 2011 22:15, Mohammed Farrag wrote: > [snip: ArabBSD website] > > Nice initiative! Best to get the website in Arabic; IMHO works best to > get members for the local community. Secondly you might want to start > a mailinglist and/or forjum, as I could not find any means of > communications apart from the contact form on the website. > > Br. /Rick > -- > http://rickvanderzwet.nl > -- *Mohammed Farrag* *FreeBSD Contributor* ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: FreeBSD extended to Arab World
Hi, Thanks for your reply. On Fri, Jun 10, 2011 at 1:08 AM, Philip Paeps wrote: > On 9 Jun 2011, at 22:15, Mohammed Farrag wrote: > > First I introduce myself, Mohammed Farrag, ArabBSD Project Manager and > > FreeBSD Contributor. We have a project to extend FreeBSD in Arab world. > > Nice initiative! > > Our website is https://sites.google.com/site/arabbsd/ and our facebook > group > > is http://www.facebook.com/home.php?sk=group_114438501975285&ap=1 > > I will be glad to receive your comments/ and recommendations. > > I don't think the "Start FreeBSD" page on the website should be linking to > an > unofficial source for VMWare... Pointing to http://vmware.com/ may be > more > suitable. > Sorry for that. I will redirect it. > > VMware.Workstation.v7.1.261024.Incl.Keymaker-EMBRACE.part1.rar > > The FreeBSD project probably does not want to be associated with > unauthorized > distribution of proprietary software. > > Best, > > - Philip > > -- > Philip Paeps > Senior Reality Engineer > Ministry of Information > > -- *Mohammed Farrag* *FreeBSD Contributor* ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: gcc-4.5 and 4.6 needs to be recompiled due to /usr/src/UPDATE: 20110608:
2011/6/9 Michael Butler : > On 06/09/11 17:18, Attilio Rao wrote: >> 2011/6/9 Mark Linimon : >>> Things that change the way the base system behaves w/rt ports need >>> version bumps. >> >> BTW, could someone provide an actual error message? >> >> I assume these errors are caused by cpumask_t going away. > > For emulators/virtualbox-ose-kmod .. > > cc -O2 -pipe -march=prescott -DRT_OS_FREEBSD -DIN_RING0 -DIN_RT_R0 > -DIN_SUP_R0 -DVBOX -DRT_WITH_VBOX -w -DVBOX_WITH_HARDENING > -DVBOX_WITH_64_BITS_GUESTS -DRT_ARCH_X86 -fno-strict-aliasing -Werror > -D_KERNEL -DKLD_MODULE -nostdinc -Iinclude -I. -Ir0drv -I. -I@ > -I@/contrib/altq -finline-limit=8000 --param inline-unit-growth=100 > --param large-function-growth=1000 -fno-common -mno-align-long-strings > -mpreferred-stack-boundary=2 -mno-sse -mno-mmx -msoft-float > -ffreestanding -fstack-protector -std=iso9899:1999 -fstack-protector > -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes > -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef > -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs > -fdiagnostics-show-option -c > /usr/ports/emulators/virtualbox-ose-kmod/work/VirtualBox-4.0.8_OSE/out/freebsd.x86/release/bin/src/vboxdrv/r0drv/freebsd/mp-r0drv-freebsd.c > > /usr/ports/emulators/virtualbox-ose-kmod/work/VirtualBox-4.0.8_OSE/out/freebsd.x86/release/bin/src/vboxdrv/r0drv/freebsd/mp-r0drv-freebsd.c: > In function 'RTMpOnOthers': > /usr/ports/emulators/virtualbox-ose-kmod/work/VirtualBox-4.0.8_OSE/out/freebsd.x86/release/bin/src/vboxdrv/r0drv/freebsd/mp-r0drv-freebsd.c:167: > error: 'cpumask_t' undeclared (first use in this function) > > /usr/ports/emulators/virtualbox-ose-kmod/work/VirtualBox-4.0.8_OSE/out/freebsd.x86/release/bin/src/vboxdrv/r0drv/freebsd/mp-r0drv-freebsd.c:167: > error: (Each undeclared identifier is reported only once > /usr/ports/emulators/virtualbox-ose-kmod/work/VirtualBox-4.0.8_OSE/out/freebsd.x86/release/bin/src/vboxdrv/r0drv/freebsd/mp-r0drv-freebsd.c:167: > error: for each function it appears in.) > > Without a version bump, it becomes impossible to determine if a > version-specific patch can be applied to accommodate the ABI change, Well, the ports should be working against -CURRENT, so what you say is not entirely true. Second thing, yeah, it is cpumask_t going away, so someone needs to sit there, check what usage of cpumask_t was done and replace with proper code. It seems usual port maintenance due by the maintainer IMHO. I'm not entirely sure how bumping __FreeBSD_version may help right now. Attilio -- Peace can only be achieved by understanding - A. Einstein ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: gcc-4.5 and 4.6 needs to be recompiled due to /usr/src/UPDATE: 20110608:
On Thu, Jun 09, 2011 at 06:01:04PM -0400, Michael Butler wrote: > On 06/09/11 17:18, Attilio Rao wrote: > > 2011/6/9 Mark Linimon : > >> Things that change the way the base system behaves w/rt ports need > >> version bumps. > > > > BTW, could someone provide an actual error message? > > > > I assume these errors are caused by cpumask_t going away. > > For emulators/virtualbox-ose-kmod .. > > cc -O2 -pipe -march=prescott -DRT_OS_FREEBSD -DIN_RING0 -DIN_RT_R0 > -DIN_SUP_R0 -DVBOX -DRT_WITH_VBOX -w -DVBOX_WITH_HARDENING > -DVBOX_WITH_64_BITS_GUESTS -DRT_ARCH_X86 -fno-strict-aliasing -Werror > -D_KERNEL -DKLD_MODULE -nostdinc -Iinclude -I. -Ir0drv -I. -I@ > -I@/contrib/altq -finline-limit=8000 --param inline-unit-growth=100 > --param large-function-growth=1000 -fno-common -mno-align-long-strings > -mpreferred-stack-boundary=2 -mno-sse -mno-mmx -msoft-float > -ffreestanding -fstack-protector -std=iso9899:1999 -fstack-protector > -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes > -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef > -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs > -fdiagnostics-show-option -c > /usr/ports/emulators/virtualbox-ose-kmod/work/VirtualBox-4.0.8_OSE/out/freebsd.x86/release/bin/src/vboxdrv/r0drv/freebsd/mp-r0drv-freebsd.c > > /usr/ports/emulators/virtualbox-ose-kmod/work/VirtualBox-4.0.8_OSE/out/freebsd.x86/release/bin/src/vboxdrv/r0drv/freebsd/mp-r0drv-freebsd.c: > In function 'RTMpOnOthers': > /usr/ports/emulators/virtualbox-ose-kmod/work/VirtualBox-4.0.8_OSE/out/freebsd.x86/release/bin/src/vboxdrv/r0drv/freebsd/mp-r0drv-freebsd.c:167: > error: 'cpumask_t' undeclared (first use in this function) > > /usr/ports/emulators/virtualbox-ose-kmod/work/VirtualBox-4.0.8_OSE/out/freebsd.x86/release/bin/src/vboxdrv/r0drv/freebsd/mp-r0drv-freebsd.c:167: > error: (Each undeclared identifier is reported only once > /usr/ports/emulators/virtualbox-ose-kmod/work/VirtualBox-4.0.8_OSE/out/freebsd.x86/release/bin/src/vboxdrv/r0drv/freebsd/mp-r0drv-freebsd.c:167: > error: for each function it appears in.) > > Without a version bump, it becomes impossible to determine if a > version-specific patch can be applied to accommodate the ABI change, This is a problem with KPI (Kernel Programming Interface) change. It is not something I would worry about, since this happens during the build of kernel module. I am worried about the vague hints on the breakage of gcc and other usermode ports. pgpI8QQId2pAZ.pgp Description: PGP signature
Re: gcc-4.5 and 4.6 needs to be recompiled due to /usr/src/UPDATE: 20110608:
> Date: Thu, 9 Jun 2011 18:26:56 -0400 > From: Attilio Rao > Sender: owner-freebsd-curr...@freebsd.org > > 2011/6/9 Michael Butler : > > On 06/09/11 17:18, Attilio Rao wrote: > >> 2011/6/9 Mark Linimon : > >>> Things that change the way the base system behaves w/rt ports need > >>> version bumps. > >> > >> BTW, could someone provide an actual error message? > >> > >> I assume these errors are caused by cpumask_t going away. > > > > For emulators/virtualbox-ose-kmod .. > > > > cc -O2 -pipe -march=prescott -DRT_OS_FREEBSD -DIN_RING0 -DIN_RT_R0 > > -DIN_SUP_R0 -DVBOX -DRT_WITH_VBOX -w -DVBOX_WITH_HARDENING > > -DVBOX_WITH_64_BITS_GUESTS -DRT_ARCH_X86 -fno-strict-aliasing -Werror > > -D_KERNEL -DKLD_MODULE -nostdinc  -Iinclude -I. -Ir0drv -I. -I@ > > -I@/contrib/altq -finline-limit=8000 --param inline-unit-growth=100 > > --param large-function-growth=1000 -fno-common  -mno-align-long-strings > > -mpreferred-stack-boundary=2 -mno-sse -mno-mmx -msoft-float > > -ffreestanding -fstack-protector -std=iso9899:1999 -fstack-protector > > -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes > > -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual  -Wundef > > -Wno-pointer-sign -fformat-extensions  -Wmissing-include-dirs > > -fdiagnostics-show-option -c > > /usr/ports/emulators/virtualbox-ose-kmod/work/VirtualBox-4.0.8_OSE/out/freebsd.x86/release/bin/src/vboxdrv/r0drv/freebsd/mp-r0drv-freebsd.c > > > > /usr/ports/emulators/virtualbox-ose-kmod/work/VirtualBox-4.0.8_OSE/out/freebsd.x86/release/bin/src/vboxdrv/r0drv/freebsd/mp-r0drv-freebsd.c: > > In function 'RTMpOnOthers': > > /usr/ports/emulators/virtualbox-ose-kmod/work/VirtualBox-4.0.8_OSE/out/freebsd.x86/release/bin/src/vboxdrv/r0drv/freebsd/mp-r0drv-freebsd.c:167: > > error: 'cpumask_t' undeclared (first use in this function) > > > > /usr/ports/emulators/virtualbox-ose-kmod/work/VirtualBox-4.0.8_OSE/out/freebsd.x86/release/bin/src/vboxdrv/r0drv/freebsd/mp-r0drv-freebsd.c:167: > > error: (Each undeclared identifier is reported only once > > /usr/ports/emulators/virtualbox-ose-kmod/work/VirtualBox-4.0.8_OSE/out/freebsd.x86/release/bin/src/vboxdrv/r0drv/freebsd/mp-r0drv-freebsd.c:167: > > error: for each function it appears in.) > > > > Without a version bump, it becomes impossible to determine if a > > version-specific patch can be applied to accommodate the ABI change, > > Well, the ports should be working against -CURRENT, so what you say is > not entirely true. > Second thing, yeah, it is cpumask_t going away, so someone needs to > sit there, check what usage of cpumask_t was done and replace with > proper code. > It seems usual port maintenance due by the maintainer IMHO. > > I'm not entirely sure how bumping __FreeBSD_version may help right now. I don't think it will. mjpegtools also fails under stable. I suspect it is really not related though the error I get is a bit different. c++ -DHAVE_CONFIG_H -I. -I.. -I.. -I/usr/local/include -I../utils -I/usr/local/include -DNDEBUG -finline-functions -fno-PIC -O2 -pipe -fno-strict-aliasing -D_THREAD_SAFE -MT newdenoise.o -MD -MP -MF .deps/newdenoise.Tpo -c -o newdenoise.o newdenoise.cc SkipList.hh: In member function 'void SkipList::Init(Status_t&, bool, const SkipList::InitParams&) [with KEY = VariableSizeAllocator::Block, VALUE = VariableSizeAllocator::Block, KEYFN = Ident, PRED = VariableSizeAllocator::Block::SortBySize, int HC = 10, ALLOC = PlacementAllocator]': SkipList.hh:546: internal compiler error: in do_SUBST, at combine.c:502 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html> for instructions. gmake[2]: *** [newdenoise.o] Error 1 gmake[2]: Leaving directory `/usr/ports/multimedia/mjpegtools/work/mjpegtools-2.0.0/y4mdenoise' -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: ober...@es.net Phone: +1 510 486-8634 Last work day before retirement is Jun 17, 2011 ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: gcc-4.5 and 4.6 needs to be recompiled due to /usr/src/UPDATE: 20110608:
"Hartmann, O." writes: > Since the notice mentioned in /usr/src/UPDATE (20110608) both gcc-4.5 > and 4.6 seems to need to be recompiled. I tried some ports with > "USE_FORTRAN= yes" setand they failed as with gcc-4.6. There was > always an error reporting: undefined reference to __cpumask_t or > similar. Do you mean stale typedef in gcc's private copy under PREFIX/lib/gccXY/gcc/*/*/include-fixed/sys/types.h ? You can fix the file manually instead of wasting cpu cycles. $ gcc46 foo.c In file included from /usr/local/lib/gcc46/gcc/x86_64-portbld-freebsd9.0/4.6.1/include-fixed/unistd.h:46:0, from foo.c:1: /usr/local/lib/gcc46/gcc/x86_64-portbld-freebsd9.0/4.6.1/include-fixed/sys/types.h:111:1: error: unknown type name '__cpumask_t' Exit 1 $ sed -n 111p /usr/local/lib/gcc46/gcc/x86_64-portbld-freebsd9.0/4.6.1/include-fixed/sys/types.h typedef __cpumask_t cpumask_t; ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [r222277] Strange GEOM, bsdlabel and ZFS behavior
On 09.06.2011 14:22, Eir Nym wrote: > GEOM will say it only after reboot. > part of dmesg log: > > GEOM_LABEL[1]: MSDOSFS: gzero: no FAT signature found. > ugen0.1: at usbus0 > uhub0: on usbus0 > ugen1.1: at usbus1 > uhub1: on usbus1 > ugen2.1: at usbus2 > uhub2: on usbus2 > ugen3.1: at usbus3 > uhub3: on usbus3 > ugen4.1: at usbus4 > uhub4: on usbus4 > GEOM_LABEL[1]: MSDOSFS: gzero: no FAT signature found. > 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: 610480MB (1250263728 512 byte sectors: 16H 63S/T 16383C) > ada0: Previously was known as ad4 > SMP: AP CPU #1 Launched! > Timecounter "TSC" frequency 1666519680 Hz quality 800 > uhub0: 2 ports with 2 removable, self powered > uhub1: 2 ports with 2 removable, self powered > uhub2: 2 ports with 2 removable, self powered > uhub3: 2 ports with 2 removable, self powered > GEOM_LABEL[1]: MSDOSFS: ada0: FAT12/16 volume not valid. > GEOM_LABEL[1]: MSDOSFS: ada0s1: no FAT signature found. > GEOM_LABEL[1]: MSDOSFS: ada0s2: no FAT signature found. > GEOM_LABEL[1]: MSDOSFS: ada0s3: FAT32 volume not valid. > GEOM_LABEL[1]: Label for provider ada0s3 is ntfs/System Reserved. > GEOM_LABEL[1]: MSDOSFS: ada0s4: FAT32 volume not valid. > GEOM_LABEL[1]: MSDOSFS: ada0s1: no FAT signature found. > g_dev_taste: make_dev_p() failed (gp->name=ada0s1, error=17) > GEOM_LABEL[1]: MSDOSFS: ada0s2: no FAT signature found. > g_dev_taste: make_dev_p() failed (gp->name=ada0s2, error=17) > GEOM_LABEL[1]: MSDOSFS: ada0s3: FAT32 volume not valid. > GEOM_LABEL[1]: Label System Reserved(ntfs/System Reserved) already > exists (ada0s3). > g_dev_taste: make_dev_p() failed (gp->name=ada0s3, error=17) > GEOM_LABEL[1]: MSDOSFS: ada0s4: FAT32 volume not valid. > g_dev_taste: make_dev_p() failed (gp->name=ada0s4, error=17) > GEOM_LABEL[1]: MSDOSFS: ada0s1a: no FAT signature found. > GEOM: ada0s1a: invalid disklabel. > GEOM_LABEL[1]: MSDOSFS: ada0s1b: no FAT signature found. > GEOM_LABEL[1]: MSDOSFS: ada0s1c: no FAT signature found. > GEOM_LABEL[1]: MSDOSFS: ada0s1a: no FAT signature found. > g_dev_taste: make_dev_p() failed (gp->name=ada0s1a, error=17) > GEOM_LABEL[1]: MSDOSFS: ada0s1b: no FAT signature found. > g_dev_taste: make_dev_p() failed (gp->name=ada0s1b, error=17) > GEOM_LABEL[1]: MSDOSFS: ada0s1a: no FAT signature found. > GEOM: ada0s1a: invalid disklabel. > g_dev_taste: make_dev_p() failed (gp->name=ada0s1a, error=17) > GEOM_LABEL[1]: MSDOSFS: ada0s1b: no FAT signature found. > g_dev_taste: make_dev_p() failed (gp->name=ada0s1b, error=17) > GEOM_LABEL[1]: MSDOSFS: ada0s1c: no FAT signature found. > g_dev_taste: make_dev_p() failed (gp->name=ada0s1c, error=17) > GEOM_LABEL[1]: MSDOSFS: ada0s1a: no FAT signature found. > g_dev_taste: make_dev_p() failed (gp->name=ada0s1a, error=17) > GEOM_LABEL[1]: MSDOSFS: ada0s1b: no FAT signature found. > g_dev_taste: make_dev_p() failed (gp->name=ada0s1b, error=17) > GEOM_LABEL[1]: MSDOSFS: ada0s1ca: no FAT signature found. > GEOM_LABEL[1]: MSDOSFS: ada0s1cb: no FAT signature found. > GEOM_LABEL[1]: MSDOSFS: ada0s1aa: no FAT signature found. > GEOM_LABEL[1]: MSDOSFS: ada0s1ab: no FAT signature found. > GEOM_LABEL[1]: MSDOSFS: ada0s1ac: no FAT signature found. > GEOM_LABEL[1]: MSDOSFS: ada0s1ca: no FAT signature found. > g_dev_taste: make_dev_p() failed (gp->name=ada0s1ca, error=17) > GEOM_LABEL[1]: MSDOSFS: ada0s1cb: no FAT signature found. > g_dev_taste: make_dev_p() failed (gp->name=ada0s1cb, error=17) > GEOM_LABEL[1]: MSDOSFS: ada0s1aa: no FAT signature found. > g_dev_taste: make_dev_p() failed (gp->name=ada0s1aa, error=17) > GEOM_LABEL[1]: MSDOSFS: ada0s1ab: no FAT signature found. > g_dev_taste: make_dev_p() failed (gp->name=ada0s1ab, error=17) > GEOM_LABEL[1]: MSDOSFS: ada0s1ac: no FAT signature found. > g_dev_taste: make_dev_p() failed (gp->name=ada0s1ac, error=17) It is strange. I think you have something incorrect in your configuration. Can you show output of these commands: 1. kldstat 2. cat /boot/loader.conf 3. grep GEOM /path/to/your/kernel/config -- WBR, Andrey V. Elsukov signature.asc Description: OpenPGP digital signature
Re: FreeBSD extended to Arab World
On Thu, Jun 9, 2011 at 10:15 PM, Mohammed Farrag wrote: > Hi Community, > > First I introduce myself, Mohammed Farrag, ArabBSD Project Manager and > FreeBSD Contributor. We have a project to extend FreeBSD in Arab world. We > aim to work in two direction. First, we will translate FreeBSD > Documentation and learning tutorials to Arabic. Second, we will have summer > training for starting work on FreeBSD development. Our website is > https://sites.google.com/site/arabbsd/ and our facebook group is > http://www.facebook.com/home.php?sk=group_114438501975285&ap=1 > I will be glad to receive your comments/ and recommendations. Great idea! Maybe we can hope to see more stuff from arabeyes in /usr/ports/arabic as well? http://projects.arabeyes.org/index.php Of course, you could also announce ArabBSD there... ;-) > Regards, > > -- > *Mohammed Farrag* -cpghost. -- Cordula's Web. http://www.cordula.ws/ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re[2]: 2 day GENERIC-current eat 2 CPU core at 100%
Great thanx ! It working ! :) Thu, 09 Jun 2011 19:40:18 +0300 письмо от Alexander Motin : > Andrey Smagin wrote: > > Hi, yesterday I tried switch event timer on i8254 - it do nothing. > > I disabled hyperthreading - now eat from 50% to 100% > > All dmesg is lines: > > (noperiph:ata3:0:-1:-1): rescan already queued > > (noperiph:ata3:0:-1:-1): rescan already queued > > (noperiph:ata2:0:-1:-1): rescan already queued > > (noperiph:ata3:0:-1:-1): rescan already queued > > (noperiph:ata3:0:-1:-1): rescan already queued > > > > I boot FreeBSD from USB with no ATA - may be it is. > > These messages are not what I expected to see, but they tell me that > your problem may be SATA related. I've got the same Intel D525MW board > and think reproduced the problem. I hope I've even fixed it. :) Retry > please with fresh CURRENT sources or at least with this patch applied: > http://svn.freebsd.org/changeset/base/222897 > > > Wed, 08 Jun 2011 20:34:42 +0300 письмо от Alexander Motin > > : > >> On 07.06.2011 20:12, Andrey Smagin wrote: > >>> vmstat -i > >>> interrupt total rate > >>> irq16: uhci3 205 0 > >>> irq20: hpet0 147924380 1126 > >>> irq23: uhci0 ehci0 522517 3 > >>> total148447102 1130 > >>> > >>> Tue, 7 Jun 2011 10:34:01 +0200 письмо от Hans Petter > >> Selasky: > On Tuesday 07 June 2011 10:09:47 Andrey Smagin wrote: > > I upgraded 2 day ago from 2010-current box on Intel D525MW. > > System very slow down after that. > > kern.hz=50 > > in systat -vmstat - 140hpet interrupts/s > > at top 25% in interrupts 25% in system > > because hyperthreading system found 4 cpu. > What does vmstat -i output? > >> Send me please full verbose dmesg and output of the `sysctl > >> kern.eventtimer` and `sysctl kern.timecounter`. > >> > >> Try to switch to another timer: > >> sysctl kern.eventtimer.timer=LAPIC > >> > >> Try to switch to periodic timers (instead): > >> sysctl kern.eventtimer.periodic=1 > > -- > Alexander Motin ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
