Re: NEW_PCIB? pcib1: failed to allocate initial I/O port window: 0x4000-0x4fff
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)? -- Andriy Gapon ___ 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 8 June 2011 23:12, Vladislav V. Prodan univers...@ukr.net wrote: 08.06.2011 17:54, Eir Nym wrote: On 8 June 2011 16:10, Vladislav V. Prodanunivers...@ukr.net 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. 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 9 June 2011 10:45, Eir Nym eir...@gmail.com wrote: On 8 June 2011 23:12, Vladislav V. Prodan univers...@ukr.net wrote: 08.06.2011 17:54, Eir Nym wrote: On 8 June 2011 16:10, Vladislav V. Prodanunivers...@ukr.net 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 a...@freebsd.org: 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 bu7c...@yandex.ru: 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: Intel at usbus0 uhub0: Intel UHCI root HUB, class 9/0, rev 1.00/1.00, addr 1 on usbus0 ugen1.1: Intel at usbus1 uhub1: Intel UHCI root HUB, class 9/0, rev 1.00/1.00, addr 1 on usbus1 ugen2.1: Intel at usbus2 uhub2: Intel UHCI root HUB, class 9/0, rev 1.00/1.00, addr 1 on usbus2 ugen3.1: Intel at usbus3 uhub3: Intel UHCI root HUB, class 9/0, rev 1.00/1.00, addr 1 on usbus3 ugen4.1: Intel at usbus4 uhub4: Intel EHCI root HUB, class 9/0, rev 2.00/1.00, addr 1 on usbus4 GEOM_LABEL[1]: MSDOSFS: gzero: no FAT signature found. ada0 at ahcich0 bus 0 scbus0 target 0 lun 0 ada0: SAMSUNG HM641JI 2AJ10001 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 0790700 inact MB/s 0,00 0,00 0,00
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 j...@freebsd.org 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 j...@freebsd.org 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);
back = 0;
}
}
--
John Baldwin
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 m...@freebsd.org: 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 Selaskyhsela...@c2i.net: 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 j...@freebsd.org 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=0xbfebfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE
Features2=0x4400CNXT-ID,xTPR
real memory = 536870912 (512 MB)
avail memory = 513818624 (490 MB)
Event timer LAPIC quality 400
ACPI APIC Table: A M I OEMAPIC
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 Version 2.0 irqs 0-23 on motherboard
kbd1 at kbdmux0
acpi0: A M I OEMXSDT 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: ACPI CPU on acpi0
cpu1: ACPI CPU on acpi0
pcib0: ACPI Host-PCI bridge port 0xcf8-0xcff on acpi0
pci0: ACPI PCI bus on pcib0
agp0: Intel 82865 host to AGP bridge on hostb0
pcib1: ACPI PCI-PCI bridge at device 1.0 on pci0
pci1: ACPI PCI bus on pcib1
vgapci0: VGA-compatible display port 0xd000-0xd0ff mem
0xd000-0xdfff,0xf7ee-0xf7ee irq 16 at device 0.0
Re: gcc-4.5 and 4.6 needs to be recompiled due to /usr/src/UPDATE: 20110608:
2011/6/9 Hartmann, O. ohart...@zedat.fu-berlin.de: 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. ohart...@zedat.fu-berlin.de: 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_114438501975285ap=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 i...@protected-networks.net: On 06/09/11 14:12, Attilio Rao wrote: 2011/6/9 Hartmann, O. ohart...@zedat.fu-berlin.de: 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 lini...@lonesome.com: 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 mfar...@freebsd.org 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 lini...@lonesome.com: 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 j...@freebsd.org 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: Found table at 0x1ff30390
APIC: Using the MADT enumerator.
MADT: Found CPU APIC ID 0 ACPI ID 1: enabled
SMP:
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 i...@protected-networks.net wrote: On 06/09/11 17:18, Attilio Rao wrote: 2011/6/9 Mark Linimon lini...@lonesome.com: 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 i...@rickvanderzwet.nlwrote: On 9 June 2011 22:15, Mohammed Farrag mfar...@freebsd.org 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 phi...@freebsd.org 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_114438501975285ap=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 i...@protected-networks.net: On 06/09/11 17:18, Attilio Rao wrote: 2011/6/9 Mark Linimon lini...@lonesome.com: 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 lini...@lonesome.com: 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 atti...@freebsd.org Sender: owner-freebsd-curr...@freebsd.org 2011/6/9 Michael Butler i...@protected-networks.net: On 06/09/11 17:18, Attilio Rao wrote: 2011/6/9 Mark Linimon lini...@lonesome.com: 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 SkipListKEY, VALUE, KEYFN, PRED, HC, ALLOC::Init(Status_t, bool, const SkipListKEY, VALUE, KEYFN, PRED, HC, ALLOC::InitParams) [with KEY = VariableSizeAllocator::Block, VALUE = VariableSizeAllocator::Block, KEYFN = IdentVariableSizeAllocator::Block, VariableSizeAllocator::Block, 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 URL: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. ohart...@zedat.fu-berlin.de 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: Intel at usbus0 uhub0: Intel UHCI root HUB, class 9/0, rev 1.00/1.00, addr 1 on usbus0 ugen1.1: Intel at usbus1 uhub1: Intel UHCI root HUB, class 9/0, rev 1.00/1.00, addr 1 on usbus1 ugen2.1: Intel at usbus2 uhub2: Intel UHCI root HUB, class 9/0, rev 1.00/1.00, addr 1 on usbus2 ugen3.1: Intel at usbus3 uhub3: Intel UHCI root HUB, class 9/0, rev 1.00/1.00, addr 1 on usbus3 ugen4.1: Intel at usbus4 uhub4: Intel EHCI root HUB, class 9/0, rev 2.00/1.00, addr 1 on usbus4 GEOM_LABEL[1]: MSDOSFS: gzero: no FAT signature found. ada0 at ahcich0 bus 0 scbus0 target 0 lun 0 ada0: SAMSUNG HM641JI 2AJ10001 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 mfar...@freebsd.org 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_114438501975285ap=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
