Re: Tmpfs panic in -current
On (27/06/2012 13:29), Kevin Lo wrote: > Kevin Lo wrote: > > Konstantin Belousov wrote: > > > On Tue, Jun 26, 2012 at 12:38:25PM +0800, Kevin Lo wrote: > > > > Konstantin Belousov wrote: > > > > > On Mon, Jun 25, 2012 at 10:03:28AM +0800, Kevin Lo wrote: > > > > > > I've observed a panic in recent -current several times but I only > > > > > > have a picture of the backtrace: > > > > > > http://people.freebsd.org/~kevlo/panic_tmpfs.jpg > > > > > > > > > > > > Does this look at all familiar to anyone? > > > > > > > > > > Can you look up the line corresponding to tmpfs_reg_resize + 0x627 > > > > > address > > > > > in your kernel ? > > > > > > > > Sure. > > > > > > > > > The screenshot looks strange. The instruction on which the kernel > > > > > trapped > > > > > is int 0x28 which should not appear in the compiled code. Kevin, do you have fuse modules loaded? It looks much like memmory corruption issue. ___ 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: Tmpfs panic in -current
On 四, 2012-06-28 at 10:09 +0300, Gleb Kurtsou wrote: > On (27/06/2012 13:29), Kevin Lo wrote: > > Kevin Lo wrote: > > > Konstantin Belousov wrote: > > > > On Tue, Jun 26, 2012 at 12:38:25PM +0800, Kevin Lo wrote: > > > > > Konstantin Belousov wrote: > > > > > > On Mon, Jun 25, 2012 at 10:03:28AM +0800, Kevin Lo wrote: > > > > > > > I've observed a panic in recent -current several times but I only > > > > > > > have a picture of the backtrace: > > > > > > > http://people.freebsd.org/~kevlo/panic_tmpfs.jpg > > > > > > > > > > > > > > Does this look at all familiar to anyone? > > > > > > > > > > > > Can you look up the line corresponding to tmpfs_reg_resize + 0x627 > > > > > > address > > > > > > in your kernel ? > > > > > > > > > > Sure. > > > > > > > > > > > The screenshot looks strange. The instruction on which the kernel > > > > > > trapped > > > > > > is int 0x28 which should not appear in the compiled code. > > Kevin, do you have fuse modules loaded? It looks much like memmory > corruption issue. No, I don't have that module loaded. # kldstat Id Refs AddressSize Name 1 14 0xc040 bab9e8 kernel 21 0xc0fac000 1d58 msdosfs_iconv.ko 32 0xc0fae000 67a8 libiconv.ko 41 0xc728e000 9000 tmpfs.ko 51 0xc789b000 4000 uhid.ko ___ 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: [CFC/CFT] large changes in the loader(8) code
27.06.2012 23:27, Andrey V. Elsukov пишет: 1. You are against from: Our loader detects that primary GPT header is damaged. It tries to read backup GPT header from the last LBA and it detects that there is "GEOM::" signature. It tries to read one previous sector and there is *valid* GPT header. Can we do the other way round? I.e. the GPT header is at the last sector. And if GEOM singature is not found at last sector of the disk and this sector is a GPT header then look at the previous sector? It is valid, because it's CRC is valid, it's self_LBA is valid. For the*FreeBSD* users it is better to don't use this GPT and just complain "i'm sorry, can't boot". The other OSes can't, and we shouldn't. -- WBR, Boris Samorodov (bsam) FreeBSD Committer, http://www.FreeBSD.org The Power To Serve ___ 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: [CFC/CFT] large changes in the loader(8) code
Am 27.06.2012 21:14, schrieb Marcel Moolenaar: > > On Jun 27, 2012, at 12:08 PM, Christian Laursen wrote: > >> On 06/27/12 16:28, John Baldwin wrote: >>> On Wednesday, June 27, 2012 8:45:45 am Andrey V. Elsukov wrote: >>> When we are in the FreeBSD, our loader can detect that device size is lower than it see and it will work. When primary header is OK, then other OSes should work with this GPT. When it isn't OK, you just can't load other OS :) >>> >>> Ah, yes. The solution to violating standards is to make sure you never >>> use standards-compliant software. That's a great argument. :) >>> >>> (Although not entirely uncommon. Standards aren't always perfect, but if >>> we had a way to not gratuitously violate them it would be nice to avoid >>> doing so.) >> >> To be standards compliant and allow whole-disk based mirroring to work at >> the same time wouldn't nested GPT work like this? > > GPTs don't nest. It is not strictly necessary to use nested GPT to have GMIRROR et.al. and GPT co-exist. And I think this is possible without violation of any standard. Just modify GEOM classes that keep state at the end of a partition to leave some spare area *behind* the GEOM data. I.e.: MBR or Primary GTP header <> GMIRROR Configuration and State <> (Spare area for Sec. GPT header) If creating a GMIRROR (or other GEOM that keeps state at the end of the provider) left at least the last 32KByte untouched (33 GPT sectors rounded up to a power of 2), GPT could use this spare space to store its Secondary Header. These sectors could be treated as part of the User Data area, i.e. logical addresses would be translated by GMIRROR to skip the GMIRROR configuration sector (which I'd enlarge to at least 4KB for alignment of "User Data 2"). This implies that the GMIRROR specification covers the whole provider (including the spare space but without the sectors holding the GMIRROR config, which are "mapped out"), since updates to the Secondary GPT must be performed on all mirrored devices. This is a complication of the current GMIRROR code, but could be added without impact on existing disk layouts. (I have not checked, whether backwards compatibility mandates introduction of a new GMIRROR class that supports such spare space after the GMIRROR config data, but I assume that there is enough spare space pre-initialized to 0 that can be used to add a flag that declares the 32 KByte beyond the end of the config data to be part of the mirror.) The only modifications required are: - If a GMIRROR is created, place the configuration sector 32 KByte before the end of the provider and mark it as "GPT compatible". (It is unknown at this point, whether GPT is to be used on the mirror at a later time.) - Tasting a provider should support looking for a valid GMIRROR (or GRAID) config sector not only at the end of the provider, but if that fails then also 32 KByte before the end of the provider. The GMIRROR is considered to be the provider for the GPT (i.e. the GMIRROR extends to 32 KByte beyond its config sector). - Creating partitions with MBR or GPT within a GMIRROR is possible without modification. The only difference is that the protected GMIRROR configuration sector is physically within the range of sectors used for the partition, but logically mapped out. The space available for partitioning is the provider size minus the size of the GMIRROR configuration, just as it used to be. - Readind and writing the mirror is allowed for all sectors in the User Data area, as in a "normal" GMIRROR. The only difference is the test for logical sectors in the last 32 KByte, for which the request is modified to be offset by a few sectors to skip the GMIRROR configuration sector. Requests that cover physical sectors before and behind these GMIRROR config sectors must be split. If instead of splitting off the final 32 KByte as "User Data 2", just the 33 sectors (of 512 Byte) required for GPT were assigned to that area, then there would never be requests that extend beyond the GMIRROR config sectors on GPT partitioned disks. But since such request were still possible if MBR partitions were used, code to treat such requests was still required in GMIRROR. There is one caveat, though: Creating a GMIRROR and then using an OS that does not know about FreeBSD to partition the disk would result in the GMIRROR configuration space being ignored. Another problem could be, that the available space in the GPT is the size of the disk minus the GMIRROR configuration sectors, i.e. there is a difference between the number of physical sectors on the disk and the number of sectors to be assigned to partitions by GPT. >> Nothing but FreeBSD would understand the freebsd-geom partition >> type, so the inner GPT device should be valid and standards >> compliant. > > If it were standards compliant, it would be discoverable by non-FreeBSD. > That clearly isn't the case -- hence it's not standards complia
Re: [CFC/CFT] large changes in the loader(8) code
On 28.06.2012 13:19, Boris Samorodov wrote: > 27.06.2012 23:27, Andrey V. Elsukov пишет: > >> 1. You are against from: >> Our loader detects that primary GPT header is damaged. It tries to read >> backup GPT header from the last LBA and it detects that there is >> "GEOM::" signature. It tries to read one previous sector and there is >> *valid* GPT header. > > Can we do the other way round? I.e. the GPT header is at the last sector. And > if GEOM singature is > not found at last sector of the disk > and this sector is a GPT header then look at the previous sector? Then this sector contains GPT table. -- 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: [CFC/CFT] large changes in the loader(8) code
Sorry for following up to self, but ... I just noticed somebody else suggesting the same method (put GMIRROR configuration below Secondary GPT header), but I think there is a problem: If GMIRROR is used to mirror whole GPT partitioned drives, then you want the GPT sectors to be considered part of the mirror (to keep them identical when GPT partitions are created/modified on the mirrored disks). But the GMIRROR configuration must not be assigned to any GPT partition. Therefore it must be protected, either by hiding it (e.g. create a special partition to hold GEOM config data, just to reserve the space within GPT, since the configuration data will still be located by looking at specific sectors of the provider), or by skipping the sectors assigned to GEOM config data in the GEOM provider that interprets them (e.g. GMIRROR). The former only works if a GMIRROR (or GELI or whatever) is created on a disk that already has GPT headers (since these lead to the GEOM config data put before the Secondary GPT header and allow the GEOM config to be marked as a special partition in that header). The latter only works on disks without GPT headers, since the size of the provider will be smaller then the physical disk. Even with the last physical disks available for GPT, the GPT headers will probably not conform to the standard, since remapping of the sectors to hide the GMIRROR config will lead to different logical sector numbers for the secondary GPT header when looked at with or without GMIRROR loaded. I still think it is possible to find a layout, that does not violate the GPT standard (use last LBAs on disk, have self-referential information like own LBA address consistent with physical block numbers and block numbers presented to users of GMIRROR et.al.). Perhaps, GMIRROR could treat its configuration sector (that is placed at the sector just below the secondary GPT header) as read only. Requests may go to all sectors below and also to the area above the GMIRROR config sector used for the GPT header, to write it to all mirrored devices). But this is also ugly, since GPT must know to not assign the GMIRROR config sector to any partition (it is read- only for user requests, but writable on each individual drive in case of GMIRROR configuration or state changes, just as it is now). The reservation was best achieved by use of a specific GPT partition for the configuration data, for which GPT headers must exist, before the GMIRROR is created (or bith must be created at the same time, but that would mix GPT knowledge into GMIRROR). All of the above is ugly, U'm afraid :( Regards, STefan ___ 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: [CFC/CFT] large changes in the loader(8) code
28.06.2012 13:41, Andrey V. Elsukov пишет: On 28.06.2012 13:19, Boris Samorodov wrote: 27.06.2012 23:27, Andrey V. Elsukov пишет: 1. You are against from: Our loader detects that primary GPT header is damaged. It tries to read backup GPT header from the last LBA and it detects that there is "GEOM::" signature. It tries to read one previous sector and there is *valid* GPT header. Can we do the other way round? I.e. the GPT header is at the last sector. And if GEOM singature is not found at last sector of the disk and this sector is a GPT header then look at the previous sector? Then this sector contains GPT table. OK, then place GEOM sector before GPT table. -- WBR, Boris Samorodov (bsam) FreeBSD Committer, http://www.FreeBSD.org The Power To Serve ___ 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: [CFC/CFT] large changes in the loader(8) code
28.06.2012 14:10, Stefan Esser пишет: All of the above is ugly, U'm afraid :( One more try to overcome it. :-) We already have freebsd-boot partition at GPT scheme. Right? Then why not use it (dedicated file/part/etc.) to store geom FreeBSD information? -- WBR, Boris Samorodov (bsam) FreeBSD Committer, http://www.FreeBSD.org The Power To Serve ___ 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: [CFC/CFT] large changes in the loader(8) code
On 28.06.2012 14:35, Wojciech Puchar wrote: >> Just modify GEOM classes that keep state at the end of a partition to >> leave some spare area *behind* the GEOM data. I.e.: >> > > what is really a problem aat all? > > just leave as is. If someone want's use gpart and mirror then mirroring every > partition is simpler. > usually not every partition needs to be mirrored. > > or mirror a whole and make gpart in it, it should still boot fine. I already reverted changes related to the GPT and GEOM metadata detection. > even better - update bsdlabel to work with >2TB devices. > MUCH better. DragonFlyBSD has disklabel64 partitioning scheme. Make a port is simple task. -- 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: [CFC/CFT] large changes in the loader(8) code
Just modify GEOM classes that keep state at the end of a partition to leave some spare area *behind* the GEOM data. I.e.: what is really a problem aat all? just leave as is. If someone want's use gpart and mirror then mirroring every partition is simpler. usually not every partition needs to be mirrored. or mirror a whole and make gpart in it, it should still boot fine. even better - update bsdlabel to work with >2TB devices. MUCH better. ___ 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: [CFC/CFT] large changes in the loader(8) code
On 28.06.2012 15:36, Boris Samorodov wrote: > 28.06.2012 14:10, Stefan Esser пишет: > >> All of the above is ugly, U'm afraid :( > > One more try to overcome it. :-) > > We already have freebsd-boot partition at GPT scheme. Right? > Then why not use it (dedicated file/part/etc.) to store > geom FreeBSD information? Recently i have ported LDM support to the FreeBSD. LDM uses 1Mbytes to store its database. All disks that are used by LDM have this database. When the disk is partitioned with MBR, LDM is stored in the last 1Mbyte. When the disk is partitioned with GPT, one partition is dedicated to this database. LDM is not just partitioning scheme, it is also LVM and can do RAID0-5. This is how Microsoft and Veritas have resolved this problem. -- 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"
about netmap NETMAP_HW_RING recv pcaket
in pkt-gen.c
tifreq.nr_ringid = (g.nthreads > 1) ? (i | NETMAP_HW_RING) : 0;
in netmap.c
if (priv->np_qlast != NETMAP_HW_RING) {
lim_tx = lim_rx = priv->np_qlast;
}
if nthreads 2.but have 8 num_tx_rings.(ixgbe default is 8)
looks like
thread #1 priv->np_qfirst = 0 priv->np_qlast = 1
thread #2 priv->np_qfirst = 1 priv->np_qlast = 2
if packet in num_tx_rings 2-7 will be lost some packet? ___
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: [CFC/CFT] large changes in the loader(8) code
On Jun 28, 2012, at 3:10 AM, Stefan Esser wrote: > > All of the above is ugly, U'm afraid :( Indeed. The only sane way is to put the metadata in a partition of its own. Every compliant OS will respect that and consequently will not scribble over the data unintentionally. Any other scheme that puts valuable data in some undocumented or unregistered location is violating the GPT spec right away and is susceptible to being clobbered unintentionally. If the metadata is in its own partition, one can document the metadata layout and providing a reference implementation. That way one increases the chance that someone, somewhere may port support for it to some other OS. Lacking widespread support for the mirroring scheme, I think that the notion that one can safely and reliably mirror entire disks (read: mirror data not owned or controlled by FreeBSD) is a very questionable one -- all one has to do is boot some other OS and start modifying one of its partitions and you've failed to achieve the objective. My advise is to leave disk mirroring to H/W or firmware solutions and use FreeBSD mirroring for FreeBSD partitions only. If you want to mirror the whole disk, don't partition the disk with non-FreeBSD partitioning schemes and partition only with FreeBSD-specific schemes or put a FreeBSD file system on the whole disk. In other words: make the whole disk private to FreeBSD. Whether or not people agree with this is besides the point. All I'm saying is that unique disk identifiers such as the "UniqueMBRSignature" (a 4 byte ID written at offset 440 in the MBR) or the "DiskGUID" (an UUID written to offset 56 in the GPT header) cannot, in general, be mirrored across disks if OSes can see the mirrored disks as independent entities. One violates the spec on grounds of making the *unique* disk identifier non-unique by presenting OSes with multiple disks that have identical IDs. -- Marcel Moolenaar mar...@xcllnt.net ___ 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"
GPU_KMS still not working CURRENT X220
I have lenovo thinkpad x220 # uname -a FreeBSD bsdx220 10.0-CURRENT FreeBSD 10.0-CURRENT #0 r237683: Thu Jun 28 08:41:40 MSK 2012 root@bsdx220:/usr/obj/usr/src/sys/MY_INTEL amd64 # pciconf -lvb vgapci0@pci0:0:2:0: class=0x03 card=0x21da17aa chip=0x01268086 rev=0x09 hdr=0x00 vendor = 'Intel Corporation' device = '2nd Generation Core Processor Family Integrated Graphics Controller' class = display subclass = VGA bar [10] = type Memory, range 64, base 0xf000, size 4194304, enabled bar [18] = type Prefetchable Memory, range 64, base 0xe000, size 268435456, enabled bar [20] = type I/O Port, range 32, base 0x6000, size 64, enabled After # kldload i915kms screen is black, if # kldunload i915kms panic # kldstat Id Refs AddressSize Name 1 23 0x8020 15d3268 kernel 21 0x81a12000 a9f3 fuse.ko 31 0x81a1d000 690a4i915kms.ko 41 0x81a87000 1ba2 iicbb.ko 54 0x81a89000 1dd7 iicbus.ko 61 0x81a8b000 1cd5 iic.ko 71 0x81a8d000 32271drm2.ko # sysctl -a | grep hw.dri | less hw.dri.0.name: i915 0x9c hw.dri.0.vm: hw.dri.0.clients: hw.dri.0.vblank: hw.dri.0.info.i915_capabilities: gen: 6 hw.dri.0.info.i915_gem_objects: 8 objects, 4636672 bytes hw.dri.0.info.i915_gem_gtt:0xfe00084cca00: p 4KiB 0001 0001 0 0 snooped (LLC) (gtt offset: , size: 1000) (p mappable) hw.dri.0.info.i915_gem_active: Active: hw.dri.0.info.i915_gem_flushing: Flushing: hw.dri.0.info.i915_gem_inactive: Inactive: hw.dri.0.info.i915_gem_pinned: Pinned: hw.dri.0.info.i915_gem_deferred_free: Deferred free: hw.dri.0.info.i915_gem_pageflip: No flip due on pipe A (plane A) hw.dri.0.info.i915_gem_request: No requests hw.dri.0.info.i915_gem_seqno: Current sequence (render ring): 0 hw.dri.0.info.i915_gem_fence_regs: Reserved fences = 0 hw.dri.0.info.i915_gem_interrupt: North Display Interrupt enable: 8c248080 hw.dri.0.info.i915_gem_hws: 0x: 0x 0x 0x 0x hw.dri.0.info.i915_gem_hws_blt: 0x: 0x 0x 0x 0x hw.dri.0.info.i915_gem_hws_bsd: 0x: 0x 0x 0x 0x hw.dri.0.info.i915_ringbuffer_data: : hw.dri.0.info.i915_ringbuffer_info: Ring render ring: hw.dri.0.info.i915_bsd_ringbuffer_data: : hw.dri.0.info.i915_bsd_ringbuffer_info: Ring gen6 bsd ring: hw.dri.0.info.i915_blt_ringbuffer_data: : hw.dri.0.info.i915_blt_ringbuffer_info: Ring blt ring: hw.dri.0.info.i915_error_state: no error state collected hw.dri.0.info.i915_rstdby_delays: w/ctx: 0, w/o ctx: 0 hw.dri.0.info.i915_cur_delayinfo: GT_PERF_STATUS: 0x0d83 hw.dri.0.info.i915_delayfreq_table: P00VIDFREQ: 0x (VID: 0) hw.dri.0.info.i915_inttoext_table: INTTOEXT01: 0x hw.dri.0.info.i915_drpc_info: RC information accurate: yes hw.dri.0.info.i915_emon_status: Not supported hw.dri.0.info.i915_ring_freq_table: GPU freq (MHz) Effective CPU freq (MHz) hw.dri.0.info.i915_gfxec: GFXEC: 0 hw.dri.0.info.i915_fbc_status: FBC disabled: no outputs hw.dri.0.info.i915_sr_status: self-refresh: disabled hw.dri.0.info.i915_gem_framebuffer: fbcon size: 1366 x 768, depth 24, 32 bpp, obj 0xfe000846da00: p 4128KiB 0041 0 0 uncached (gtt offset: 00064000, size: 00408000) (p mappable) hw.dri.0.info.i915_gen6_forcewake_count_info: forcewake count = 0 hw.dri.0.info.i915_swizzle_info: bit6 swizzle for X-tiling = bit9/bit10 hw.dri.0.info.i915_ppgtt_info: GFX_MODE: 0x0a00 hw.dri.0.info.i915_gem_wired_pages: 1132 hw.dri.0.wedged: 0 hw.dri.0.max_freq: 1300 hw.dri.0.cache_sharing: 0 hw.dri.0.sync_exec: 0 hw.dri.0.fix_mi: 0 hw.dri.0.intr_pf: 0 hw.dri.0.busid: pci::00:02.0 hw.dri.0.modesetting: 1 hw.dri.debug: 2 hw.dri.notyet: 0 hw.dri.vblank_offdelay: 5000 hw.dri.timestamp_precision: 20 # less /var/log/messages Jun 28 17:32:17 bsdx220 kernel: drmn0: on vgapci0 Jun 28 17:32:17 bsdx220 kernel: info: [drm] MSI enabled 1 message(s) Jun 28 17:32:17 bsdx220 kernel: info: [drm] AGP at 0xe000 256MB Jun 28 17:32:17 bsdx220 kernel: iicbus0: on iicbb0 addr 0xff Jun 28 17:32:17 bsdx220 kernel: iic0: on iicbus0 Jun 28 17:32:17 bsdx220 kernel: iic1: on iicbus1 Jun 28 17:32:17 bsdx220 kernel: iicbus2: on iicbb1 addr 0xff Jun 28 17:32:17 bsdx220 kernel: iic2: on iicbus2 Jun 28 17:32:17 bsdx220 kernel: iic3: on iicbus3 Jun 28 17:32:17 bsdx220 kernel: iicbus4: on iicbb2 addr 0xff Jun 28 17:32:17 bsdx220 kernel: iic4: on iicbus4 Jun 28 17:32:17 bsdx220 kernel: iic5: on iicbus5 Jun 28 17:32:17 bsdx220 kernel: iicbus6: on iicbb3 addr 0xff Jun 28 17:32:17 bsdx220 kernel: iic6: on iicbus6 Jun 28 17:32:17 bsdx220 kernel: iic7: on iicbus7 Jun 28 17:32:17 bsdx220 kernel: iicbus8: on iicbb4 addr 0xff Jun 28 17:32:17 bsdx220 kernel: iic8: on iicbus8 Jun 28 17:32:17 bsdx220 kernel: iic9: on iicbus9 Jun 28 17:32:17
Re: GPU_KMS still not working CURRENT X220
On Thu, Jun 28, 2012 at 8:45 AM, Andrey Fesenko wrote: > I have lenovo thinkpad x220 > > # uname -a > FreeBSD bsdx220 10.0-CURRENT FreeBSD 10.0-CURRENT #0 r237683: Thu Jun > 28 08:41:40 MSK 2012 root@bsdx220:/usr/obj/usr/src/sys/MY_INTEL > amd64 > > # pciconf -lvb > vgapci0@pci0:0:2:0: class=0x03 card=0x21da17aa chip=0x01268086 > rev=0x09 hdr=0x00 > vendor = 'Intel Corporation' > device = '2nd Generation Core Processor Family Integrated > Graphics Controller' > class = display > subclass = VGA > bar [10] = type Memory, range 64, base 0xf000, size 4194304, enabled > bar [18] = type Prefetchable Memory, range 64, base 0xe000, > size 268435456, enabled > bar [20] = type I/O Port, range 32, base 0x6000, size 64, enabled > > After # kldload i915kms screen is black, if # kldunload i915kms panic Don't do this. It has been clearly stated that i915kms my not be unloaded and that attempting to unload it WILL panic the system. Also, don't load i945kms. This WILL lock up the system with a blank screen. The modules required are autoloaded during Xorg initialization. Just make absolutely sure that you have the latest version of xf-video-intel. (If you installed a rather early version of the KMS code, it is possible that you have two xf-video.intel* ports in your tree, thought I don't expect this is the case. -- R. Kevin Oberman, Network Engineer E-mail: kob6...@gmail.com ___ 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: [CFC/CFT] large changes in the loader(8) code
On Thu, Jun 28, 2012 at 08:33:17AM -0700, Marcel Moolenaar wrote: > > On Jun 28, 2012, at 3:10 AM, Stefan Esser wrote: > > > > All of the above is ugly, U'm afraid :( > > Indeed. The only sane way is to put the metadata in a partition of its own. > Every compliant OS will respect that and consequently will not scribble over > the data unintentionally. Any other scheme that puts valuable data in some > undocumented or unregistered location is violating the GPT spec right away > and is susceptible to being clobbered unintentionally. If the user runs: # gpart create -s GPT /dev/mirror/foo for me it is obvious that he wants to partition the mirror device and not individual disks. Because the mirror was configured earlier, do you expect gmirror to somehow detect that someone is writting GPT metadata later and magically place GPT metadata on the raw disk and move mirror's metadata to some magic partition? Not to mention that the mirror itself doesn't have to be configured on top of raw disks. And not to mention that the mirror may never be partitioned. If GPT in your opinion is limited only to raw disks then I guess the best way to fix that is to refuse to configure GPT on anything except raw disks (which was already proposed by Andrey?). In my opinion this is unacceptable, but I think this is what you are suggesting. One of the GEOM design goals was to be flexible. Let the user decide in what order he wants to configure various layers. How do you know that in every possible scenerio software mirroring should come after partitioning and encryption after mirroring? Why can't we provide flexible tools to the user and let him decide? Maybe GPT nesting violates standards, but why can't we support it as an extention, really? I recognize the need to warn users if they use FreeBSD-specific features. We do that with non-standard APIs. So how about this. Let's modify gpart(8) to print a warning if GPT is configured on something else than raw disk. Let's the warning say that such configuration is non-standard and problems are expected if the disk is shared between other OSes. In my opinion that's fair. With such a warning in place, I think we can allow users to decide on their own if they really want that or not. Then, we can also improve FreeBSD boot loader to play nice with FreeBSD-specific extensions. -- Pawel Jakub Dawidek http://www.wheelsystems.com FreeBSD committer http://www.FreeBSD.org Am I Evil? Yes, I Am! http://tupytaj.pl pgpk4jIfg3rJt.pgp Description: PGP signature
Re: about netmap NETMAP_HW_RING recv pcaket
On Thu, Jun 28, 2012 at 09:24:59PM +0800, r...@9du.org wrote:
> in pkt-gen.c
> tifreq.nr_ringid = (g.nthreads > 1) ? (i | NETMAP_HW_RING) : 0;
>
> in netmap.c
> if (priv->np_qlast != NETMAP_HW_RING) {
> lim_tx = lim_rx = priv->np_qlast;
> }
>
>
> if nthreads 2.but have 8 num_tx_rings.(ixgbe default is 8)
> looks like
> thread #1 priv->np_qfirst = 0 priv->np_qlast = 1
> thread #2 priv->np_qfirst = 1 priv->np_qlast = 2
>
> if packet in num_tx_rings 2-7 will be lost some packet?
if you decide to attach to individual rings then it is
up to you to bind enough threads as there are rings.
pkt-gen.c is only a test program, not all combinations
of options are necessary meaningful
cheers
luigi
___
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: Occassional "permission denied" in the middle of a large transfer over NFS
Just a note to say I have tested this on -CURRENT with the new nfs server and it is still the case. On the client (FreeBSD seaurchin 8.3-RELEASE-p3 FreeBSD 8.3-RELEASE-p3 #0: Tue Jun 12 00:39:29 UTC 2012 r...@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC amd64) [root@seaurchin /mnt/nfs/vm]# date ; tar -cf foo.tar /var/nfsen/profiles-data/ ; date Thu Jun 28 20:12:36 BST 2012 tar: Removing leading '/' from member names tar: Write error Thu Jun 28 20:12:38 BST 2012 [root@seaurchin /mnt/nfs/vm]# on the Server [root@fbsd /var/tmp]# uname -a ; date ; while true ; do mount /dev/md0 /mnt/tmp/ ; umount /mnt/tmp ; done FreeBSD fbsd 10.0-CURRENT FreeBSD 10.0-CURRENT #22 r237646: Wed Jun 27 19:13:26 BST 2012 t...@fbsd.bmk.namesco.net:/usr/obj/usr/src/sys/unsane-vm amd64 Thu Jun 28 20:12:38 BST 2012 ^C [root@fbsd /var/tmp]# any suggestions welcome. Vince On 27/06/2012 16:27, Vincent Hoffman wrote: > Hi, > After only one off-list reply from the author of kern/136865 (see below) > after asking -questions, I thought it worth asking -CURRENT. > Basically: > > I seem to have run into the problems described in this old thread. > http://lists.freebsd.org/pipermail/freebsd-questions/2004-April/044927.html > > tl:dr mountd may give incorrect permission denied errors when it is > refreshing the exports list due to non-atomic operations, /sbin/mount has > code that sends SIGHUP to > mountd on any mount operation, which implies that any manual mount > request would cause the problem. > > Currently I have still only tested on 8.3-RELEASE but the svn log doesnt > seem to mention a fix since then. I'm currently taking a VM up to > -CURRENT to test. > > Looking though old PRs I see the following related. > kern/131342 > kern/136865 (with patch for 7.2 and links to > http://nfse.sourceforge.net/ for -CURRENT ) > > Does anyone who is qualified (sadly not me) feel like looking at the > code to see if its suitable for inclusion in part/whole as not having > NFS transfers interrupted by local mount operations on the nfs server > would be very handy :) > > > thanks, Vince > > > ___ > 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: [CFC/CFT] large changes in the loader(8) code
On Thu, 28 Jun 2012 08:33:17 -0700 Marcel Moolenaar wrote: > My advise is to leave disk mirroring to H/W or firmware solutions and > use FreeBSD mirroring for FreeBSD partitions only. If you want to > mirror the whole disk, don't partition the disk with non-FreeBSD > partitioning schemes and partition only with FreeBSD-specific schemes > or put a FreeBSD file system on the whole disk. In other words: make > the whole disk private to FreeBSD. If I gmirror the entire disk, I already expressed my interest to make the whole disk private to FreeBSD, haven't I? Or are you suggesting to convince all BIOS vendors to include the ability to boot from some kind of FreeBSD private partitioning scheme (not MBR as it is not suitable, not GPT as you are not OK to use it on a gmirror)? > Whether or not people agree with this is besides the point. All I'm > saying is that unique disk identifiers such as the > "UniqueMBRSignature" (a 4 byte ID written at offset 440 in the MBR) > or the "DiskGUID" (an UUID written to offset 56 in the GPT header) > cannot, in general, be mirrored across disks if OSes can see the > mirrored disks as independent entities. One violates the spec on > grounds of making the *unique* disk identifier non-unique by > presenting OSes with multiple disks that have identical IDs. What about multipathing? In case the disk is attached via two paths but multipath is not enabled, the OS sees the same disk (and the same identical unique disk identifier) multiple times. Is this a violation of the spec too? Bye, Alexander. -- http://www.Leidinger.netAlexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 ___ 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: [CFC/CFT] large changes in the loader(8) code
On Thu, 28 Jun 2012 14:49:02 -0500, Alexander Leidinger wrote: What about multipathing? In case the disk is attached via two paths but multipath is not enabled, the OS sees the same disk (and the same identical unique disk identifier) multiple times. Is this a violation of the spec too? Good point; does gmirror and gmultipath play together nicely? ___ 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: [CFC/CFT] large changes in the loader(8) code
On Jun 28, 2012, at 10:25 AM, Pawel Jakub Dawidek wrote: > On Thu, Jun 28, 2012 at 08:33:17AM -0700, Marcel Moolenaar wrote: >> >> On Jun 28, 2012, at 3:10 AM, Stefan Esser wrote: >>> >>> All of the above is ugly, U'm afraid :( >> >> Indeed. The only sane way is to put the metadata in a partition of its own. >> Every compliant OS will respect that and consequently will not scribble over >> the data unintentionally. Any other scheme that puts valuable data in some >> undocumented or unregistered location is violating the GPT spec right away >> and is susceptible to being clobbered unintentionally. > > If the user runs: > > # gpart create -s GPT /dev/mirror/foo > > for me it is obvious that he wants to partition the mirror device and > not individual disks. It could definitely be interpreted as the user knowing what he/she wants and as such design an infrastructure around this assumption. If users were at least as knowledgable as developers, my concerns wouldn't be as big. But we all know how knoweldgable users can be and kike it or not, even developers aren't gurus in everything. We may think to know stuff, but in practice we're just as clueless in cases as users -- more clueless even sometimes. So you may think the intend is obvious, but you should know better. > Let's modify gpart(8) to print a warning if GPT is configured on > something else than raw disk. Let's the warning say that such > configuration is non-standard and problems are expected if the disk is > shared between other OSes. Yes. I think we finally reached the point we should have reached years ago. With the proper tooling, our flexible infrastructure can be used in a safe and complaint way while still giving the freedom to those who unwisely think they know better. Build it and I'll concur. -- Marcel Moolenaar mar...@xcllnt.net ___ 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: [CFC/CFT] large changes in the loader(8) code
Pawel Jakub Dawidek wrote: On Thu, Jun 28, 2012 at 08:33:17AM -0700, Marcel Moolenaar wrote: On Jun 28, 2012, at 3:10 AM, Stefan Esser wrote: All of the above is ugly, U'm afraid :( Indeed. The only sane way is to put the metadata in a partition of its own. Every compliant OS will respect that and consequently will not scribble over the data unintentionally. Any other scheme that puts valuable data in some undocumented or unregistered location is violating the GPT spec right away and is susceptible to being clobbered unintentionally. If the user runs: # gpart create -s GPT /dev/mirror/foo for me it is obvious that he wants to partition the mirror device and not individual disks. Because the mirror was configured earlier, do you expect gmirror to somehow detect that someone is writting GPT metadata later and magically place GPT metadata on the raw disk and move mirror's metadata to some magic partition? Not to mention that the mirror itself doesn't have to be configured on top of raw disks. And not to mention that the mirror may never be partitioned. If GPT in your opinion is limited only to raw disks then I guess the best way to fix that is to refuse to configure GPT on anything except raw disks (which was already proposed by Andrey?). In my opinion this is unacceptable, but I think this is what you are suggesting. One of the GEOM design goals was to be flexible. Let the user decide in what order he wants to configure various layers. How do you know that in every possible scenerio software mirroring should come after partitioning and encryption after mirroring? Why can't we provide flexible tools to the user and let him decide? Maybe GPT nesting violates standards, but why can't we support it as an extention, really? I recognize the need to warn users if they use FreeBSD-specific features. We do that with non-standard APIs. So how about this. Let's modify gpart(8) to print a warning if GPT is configured on something else than raw disk. Let's the warning say that such configuration is non-standard and problems are expected if the disk is shared between other OSes. In my opinion that's fair. With such a warning in place, I think we can allow users to decide on their own if they really want that or not. Then, we can also improve FreeBSD boot loader to play nice with FreeBSD-specific extensions. I think this is valid point of view. FreeBSD already does things not supported by other OSes and I am completely fine with it - I am running FreeBSD on servers, not sharing anything with other OSes so I prefer extended FreeBSD specific features over 100% standard compliant behaviour crippling SW mirroring etc. I think that our tools should support / provide all standard compliant (compatible) features, but let user to choose any other extended non-compatible features if user wants it. Even if it can be seen as foot shooting by somebody else. And maybe one day our solution will be widespread and taken as a standard. Miroslav Lachman ___ 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: [CFC/CFT] large changes in the loader(8) code
On Jun 28, 2012, at 12:49 PM, Alexander Leidinger wrote: > On Thu, 28 Jun 2012 08:33:17 -0700 Marcel Moolenaar > wrote: > >> My advise is to leave disk mirroring to H/W or firmware solutions and >> use FreeBSD mirroring for FreeBSD partitions only. If you want to >> mirror the whole disk, don't partition the disk with non-FreeBSD >> partitioning schemes and partition only with FreeBSD-specific schemes >> or put a FreeBSD file system on the whole disk. In other words: make >> the whole disk private to FreeBSD. > > If I gmirror the entire disk, I already expressed my interest to make > the whole disk private to FreeBSD, haven't I? No. All you've done is type some commands. There's no inherent value in it that relays that you know what you're doing. I have no problem accepting that you do in fact know what you're doing, but that doesn't mean that anyone who types the same sequence of commands is as skilled as you are -- that would be a silly inference. What you need to do is not have it be about you, but about some random user. > Or are you suggesting to > convince all BIOS vendors to include the ability to boot from some kind > of FreeBSD private partitioning scheme (not MBR as it is not > suitable, not GPT as you are not OK to use it on a gmirror)? I would be having less problems if the mirroring didn't force the backup GPT header in anything but the last sector. If the metadata was somewhere else, then we wouldn't need to kluge various places to deal with the ambiguity and visible interoperability problems of the various tools and OSes. Thus, it's not that I object to the mirroring per se, just to the mirroring as it is currently implemented with gmirror. > What about multipathing? In case the disk is attached via two paths but > multipath is not enabled, the OS sees the same disk (and the same > identical unique disk identifier) multiple times. Is this a violation > of the spec too? It's the same disk, isn't it? The OS can actually use the property of the ID to infer that it has already seen this disk and not create multiple device nodes. -- Marcel Moolenaar mar...@xcllnt.net ___ 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: [CFC/CFT] large changes in the loader(8) code
On Thu, Jun 28, 2012 at 02:54:43PM -0700, Marcel Moolenaar wrote: > On Jun 28, 2012, at 12:49 PM, Alexander Leidinger wrote: > > Or are you suggesting to > > convince all BIOS vendors to include the ability to boot from some kind > > of FreeBSD private partitioning scheme (not MBR as it is not > > suitable, not GPT as you are not OK to use it on a gmirror)? > > I would be having less problems if the mirroring didn't force the backup > GPT header in anything but the last sector. [...] GPT backup header is placed in the last sector of the mirror device, just like the user asked. Gmirror doesn't force anything. User decides to put GPT partitioning on the mirror device instead of raw disk. Gmirror doesn't even know and doesn't have to know how the user uses data area on the mirror device. > [...] If the metadata was somewhere > else, then we wouldn't need to kluge various places to deal with the > ambiguity and visible interoperability problems of the various tools and > OSes. [...] Where is "somewhere else", exactly? If somewhere else on this disk, then where? At the begining of the disk? Then you would complain that it keeps metadata where the primary header should be located and also MBR metadata, BSDlabel metadata, etc. Somewhere in the middle of the disk? Some future GPTng may want to use the same spot, but also gmirror-unaware boot loader will see corrupted data (shifted by one sector). Come on... If somewhere else is not on this disk, then I'm sorry, but this is totally impractical. Disks are the place you store stuff. In 99% of the cases there is no other place to store it, but the disk itself. Should we ask users to use additional disk to keep mirror's metadata? > [...] Thus, it's not that I object to the mirroring per se, just to the > mirroring as it is currently implemented with gmirror. Do you know software RAID (>=1) or volume manager that doesn't keep metadata on component disks? PS. We are discussing two totally different things here: 1. Is placing GPT on anything but raw disk violates the spec? I can agree that it does and I'm happy with gpart(8) growing a warning. 2. How to do software mirroring. Besides trying really hard I'm not sure what alternative are you proposing. Could you be more specific and describe how gmirror should be implemented in your opinion? > > What about multipathing? In case the disk is attached via two paths but > > multipath is not enabled, the OS sees the same disk (and the same > > identical unique disk identifier) multiple times. Is this a violation > > of the spec too? > > It's the same disk, isn't it? The OS can actually use the property > of the ID to infer that it has already seen this disk and not create > multiple device nodes. You cannot trust some id that is found on disk to be unique, as all your assumptions break when the user decides to dd(1)-copy content of this disk to another disk, for example. -- Pawel Jakub Dawidek http://www.wheelsystems.com FreeBSD committer http://www.FreeBSD.org Am I Evil? Yes, I Am! http://tupytaj.pl pgp4nneOO8jiW.pgp Description: PGP signature
Re: panic's in 10-CURRENT r235646 in VMware
Hi Matthais, On 06/27/12 01:19, Matthias Apitz wrote: > El día Saturday, June 16, 2012 a las 08:11:40AM -0400, John Baldwin escribió: > >> On Saturday, June 16, 2012 04:51:06 AM Matthias Apitz wrote: >>> El día Friday, June 15, 2012 a las 08:18:22AM -0400, John Baldwin escribió: > the panic says: > mutex page lock not owned at /usr/src/sys/vm/vm_page.c:2060 > > I have a screen shoot here: > http://www.unixarea.de/aurora-panic.gif > > Installed and started (via rc.conf) is the port open-vm-tools-425873,1; > > Thx > > matthias Can you get a stack trace? > > The attached patch file (to be replaced in > open-vm-tools/files/patch-vmmemctl-os.c) > solved the problem for me; thanks, John > > matthias > Thanks! I've updated the port with this and the other patches you sent and it seems to build and work properly on 10-CURRENT. Steve ___ 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: [CFC/CFT] large changes in the loader(8) code
On Jun 28, 2012, at 4:07 PM, Pawel Jakub Dawidek wrote: >> >> I would be having less problems if the mirroring didn't force the backup >> GPT header in anything but the last sector. [...] > > GPT backup header is placed in the last sector of the mirror device, > just like the user asked. Gmirror doesn't force anything. User decides > to put GPT partitioning on the mirror device instead of raw disk. > Gmirror doesn't even know and doesn't have to know how the user uses > data area on the mirror device. This really is a cop-out paragraph. >> [...] If the metadata was somewhere >> else, then we wouldn't need to kluge various places to deal with the >> ambiguity and visible interoperability problems of the various tools and >> OSes. [...] > > Where is "somewhere else", exactly? I already suggested a few things in this thread. Go read it. I'm bored now, so I'll just wait for UEFI booting to be forced upon those who mirror the whole disk with gmirror. I think that's when we will have a more substantial and meaningful continuation of this thread. -- Marcel Moolenaar mar...@xcllnt.net ___ 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: [CFC/CFT] large changes in the loader(8) code
Pawel Jakub Dawidek wrote in <20120628230725.gb1...@garage.freebsd.pl>: pj> PS. We are discussing two totally different things here: pj> 1. Is placing GPT on anything but raw disk violates the spec? I can pj>agree that it does and I'm happy with gpart(8) growing a warning. I agree that there is a sort of violation, but in practice most of implementations which use GPT can recognize the backup header as long as the primary one is not corrupted by using the alternative LBA field. One thing we have to consider is what happens when the primary header becomes broken. In that case and if a GEOM metadata is placed at the end of the raw disk, GPT will be lost and it cannot recover by non-GEOM-aware software including BIOS and other OS. Also, even for FreeBSD it causes a boot failure. The modification which ae@ proposes mitigates this case. Of course, maybe BIOS or EFI will not recognize the corrupted header because the backup header is not located at the end. In that case all of the partitions are not recognized and the FreeBSD does not boot. This is the trade-off when we use GPT in a logical volume provided by GEOM. In short, the risk is that backup header does not work as a backup when the primary is broken. I agree that putting a warning about that is good and enough. Whether this risk is acceptable or not depends on the sysadmin. Also, we can describe the pros and cons in detail in a section of the handbook because I and wblock@ are working on updating it. pj> 2. How to do software mirroring. Besides trying really hard I'm not sure pj>what alternative are you proposing. Could you be more specific and pj>describe how gmirror should be implemented in your opinion? I do not think this topic is related to ae@'s change and this should be discussed in a separate thread. His change aims to support a non-standard GPT header location in a quite limited situation, not actively promote such a configuration. The issue of GPT+GEOM is not limited to gmirror. Just putting GEOM::LABEL metadata causes the same issue. -- Hiroki pgp6Fd1NnM4r5.pgp Description: PGP signature
