misc/161677: Probably bug in gptboot

2011-10-15 Thread Alexander Yerenkow 

>Number: 161677
>Category:   misc
>Synopsis:   Probably bug in gptboot
>Confidential:   no
>Severity:   serious
>Priority:   low
>Responsible:freebsd-bugs
>State:  open
>Quarter:
>Keywords:   
>Date-Required:
>Class:  sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Sat Oct 15 09:30:05 UTC 2011
>Closed-Date:
>Last-Modified:
>Originator: Alexander Yerenkow
>Release:FreeBSD-9-r226337
>Organization:
>Environment:
>Description:
When working with disk images, I have problems with boot them.
Booting went fine until screen with boot choices, and with FreeBSD logo, after 
choicing any, finished with message:
Can't work out which disk we are booting from.
Guessed BIOS device 0x not found by probes, defaulting to disk0:

panic: free: guard1 fail @ 0x3f2880b8 from 
sys/boot/i386/loader/../../common/module.c:1004

If I trying to boot in VirtualBox, then all the same, except that there's no 
last message, about panic, VirtBox just hangs.
>How-To-Repeat:
This is my way to make it:

touch $imagefile
truncate -s 4G $imagefile
mdconfig -af $imagefile -u $u
gpart create -s gpt /dev/md$u
gpart add -s 64k -t freebsd-boot -i 1 md$u
gpart add -t freebsd-ufs -s 2G -i 2 md$u
gpart add -t freebsd-swap -i 3 md$u
newfs -Uj /dev/md${u}p2
mount -o rw,noatime /dev/md${u}p2 $mountdir
.
make installworld DESTDIR=$mountdir
make distribution DESTDIR=$mountdir
make installkernel DESTDIR=$mountdir
gpart bootcode -b $mountdir/boot/pmbr md$u
gpart bootcode -p $mountdir/boot/gptboot -i 1 md$u


That's it, we created image;
Now any one to test:
1. VBoxManage convertfromraw $imagefile $imagevdi --format VDI -- and test in 
VirtualBox;
2. dd if=/$imagefile of=/dev/da* bs=1M  -- write to some USB disk, and boot 
from it.
>Fix:
Use mbr probably? :)


>Release-Note:
>Audit-Trail:
>Unformatted:
___
freebsd-bugs@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"

Re: kern/159663: sockets don't work though nullfs mounts

2011-10-15 Thread Mikolaj Golub 

On Mon, 26 Sep 2011 00:58:03 +0300 Mikolaj Golub wrote to Robert Millan:

 MG> Hi,

 MG> On Sun, 25 Sep 2011 17:32:27 +0200 Robert Millan wrote:

 RM>> 2011/9/24 Robert Millan :
 >>> I found a thread from 2007 with further discussion about this problem:
 >>>
 >>> http://lists.freebsd.org/pipermail/freebsd-fs/2007-February/002669.html

 RM>> Hi,

 RM>> I've looked at the situation in a bit more detail, for now only with
 RM>> sockets in mind (not named pipes).  My understanding is (please
 RM>> correct me if I'm wrong):

 RM>> - nullfs holds reference counts for each vnode, but sockets have their
 RM>> own mechanism for reference counting (so_count / soref / sorele).
 RM>> vnode reference counting doesn't protect against socket being closed,
 RM>> which would leave a stale pointer in the upper nullfs layer.

 RM>> - Increasing the reference count of the socket itself can't be done in
 RM>> null_nodeget() because this function is merely a getter whose call
 RM>> doesn't indicate any meaningful event.

 RM>> - It's not clear to me that there's any event in time where the socket
 RM>> reference can be increased.  If mounting a nullfs were that event,
 RM>> then all existing sockets would be soref'ed but we wouldn't be
 RM>> soref'ing future sockets created in the lower layer after the mount.
 RM>> This doesn't seem correct.

 RM>> - Possible solution: null_nodeget() semantics are replaced with
 RM>> something that actually allows vnodes in the upper layer to be created
 RM>> and destroyed.

 RM>> - Possible solution: upper layer has a memory structure to keep track
 RM>> of which sockets in the lower layer have been soref'ed.

 MG> It looks like there is no need in setting vp->v_un = lowervp->v_un for
 MG> VFIFO. They work without this modification bypassing vnode operations to 
lover
 MG> node and lowervp->v_un is used.

 MG> The issue is only with local sockets, because when bind or connnect is 
called
 MG> for nullfs file the upper v_un is used.

 MG> For me the approach "vp->v_un = lowervp->v_un" has many complications. May 
be
 MG> it is much easier to use always only lower vnode? What we need for this is 
to
 MG> make bind and connect get the lower vnode when they are called on nullfs 
file.

Thinking more about "vp->v_un = lowervp->v_un" approach it looks for me that
there should not be any coherency issues on contents of v_un between the two
file system layers (the main worry about this approach in the thread mentioned
above).

Consider a scenario when binding to lower fs vnode and then connnecting to the
upper fs path.

On connect lookup returns nullfs node with:

lvnp->v_un = bind_socket
uvnp->v_un = bind_socket

uvnp is locked (usecount is 1).

bind_socket is used to establish the connection. After the connection is
established uvnp is released by vput(), usecount is 0, so nullfs vnode is
deactivated and destroyed.

Thus uvnp->v_un has short time of life and it looks like it can't be stale
during this time.

When we bind to the upper fs vnode, in bind VOP_CREATE will return nullfs
node with:

lvnp->v_un = NULL
uvnp->v_un = NULL

bind sets uvnp->v_un, lvnp->v_un remains NULL. The nullfs node remains active
until bind socket is closed, so on connect uvnp->v_un of this node is used.
The connection to lower fs will return ECONNREFUSE.

Thus I don't see a scenario when uvnp->v_un would be stale. I did some crash
testing and did not manage to panic the system.

But the issue is that if we bind to an upper fs path, we can't connect to the
lower fs path. This behavior contradicts with overall nullfs behavior (all
changes done on the upper layer are seen from the lower layer) and is more
unionfs-like.  That is why my proposal (return lover vnode instead of upper
vnode in null_lookup and null_create if the vnode type is VSOCK) looks for me
more interesting. But as I wrote it also has an issue: you can bind using the
upper fs path and then unmount nullfs without force while the socket is still
bound.

The updated patch can be found here:

http://people.freebsd.org/~trociny/nullfs.VSOCK.patch

Anyway, for me any of these solutions, although not ideal, looks like better
than having nothing at all, maybe just documenting the behavior in BUGS
section.

 MG> As a proof of concept below is a patch that implements it. Currently I am 
not
 MG> sure that vrele/vref magic is done properly, but it looks like it works for
 MG> me.

 MG> The issues with this approach I see so far:

 MG> - we need an additional flag for namei;

 MG> - nullfs can be unmounted with a socket file still being opened.

 MG> -- 
 MG> Mikolaj Golub

-- 
Mikolaj Golub
___
freebsd-bugs@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"

Re: bin/161526: commit references a PR

2011-10-15 Thread dfilter service 
The following reply was made to PR bin/161526; it has been noted by GNATS.

From: dfil...@freebsd.org (dfilter service)
To: bug-follo...@freebsd.org
Cc:  
Subject: Re: bin/161526: commit references a PR
Date: Sat, 15 Oct 2011 19:08:32 + (UTC)

 Author: trociny
 Date: Sat Oct 15 19:08:22 2011
 New Revision: 226403
 URL: http://svn.freebsd.org/changeset/base/226403
 
 Log:
   In r225809 the intention was to send VEOF only once if STDIN was not a
   terminal. Unfortunately the fix was incorrect and for flushtime > 0 it
   keept sending VEOF.
   
   Sent VEOF generates ^D\b\b echoed by the terminal, which was reported
   in bin/161526. Note, we still send VEOF at least once. Otherwise
   commands like below would hang forever:
   
 echo 1 |script /tmp/script.out cat
   
   PR:  bin/161526
   Reported by: Adrian Wontroba , Stefan Bethke 

   Tested by:   Stefan Bethke 
   MFC after:   3 days
 
 Modified:
   head/usr.bin/script/script.c
 
 Modified: head/usr.bin/script/script.c
 ==
 --- head/usr.bin/script/script.c   Sat Oct 15 18:41:25 2011
(r226402)
 +++ head/usr.bin/script/script.c   Sat Oct 15 19:08:22 2011
(r226403)
 @@ -163,12 +163,15 @@ main(int argc, char *argv[])
FD_SET(master, &rfd);
if (readstdin)
FD_SET(STDIN_FILENO, &rfd);
 -  if ((!readstdin && ttyflg) || flushtime > 0) {
 -  tv.tv_sec = !readstdin && ttyflg ? 1 :
 -  flushtime - (tvec - start);
 +  if (!readstdin && ttyflg) {
 +  tv.tv_sec = 1;
tv.tv_usec = 0;
tvp = &tv;
readstdin = 1;
 +  } else if (flushtime > 0) {
 +  tv.tv_sec = flushtime - (tvec - start);
 +  tv.tv_usec = 0;
 +  tvp = &tv;
} else {
tvp = NULL;
}
 ___
 svn-src-...@freebsd.org mailing list
 http://lists.freebsd.org/mailman/listinfo/svn-src-all
 To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
 
___
freebsd-bugs@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"

kern/161692: Error in IPFW code halts kernel compile in 9.0-BETA3

2011-10-15 Thread Brett Glass 

>Number: 161692
>Category:   kern
>Synopsis:   Error in IPFW code halts kernel compile in 9.0-BETA3
>Confidential:   no
>Severity:   serious
>Priority:   high
>Responsible:freebsd-bugs
>State:  open
>Quarter:
>Keywords:   
>Date-Required:
>Class:  sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Sat Oct 15 19:50:07 UTC 2011
>Closed-Date:
>Last-Modified:
>Originator: Brett Glass
>Release:9.0-BETA3
>Organization:
>Environment:
>Description:
Attempt to build stripped-down kernel in 9.0-BETA3 with the IPFIREWALL option 
causes compiler to halt process with error. Error occurs at 
netinet/ipfw/ip_fw_pfil.c, line 185, where compiler complains that the variable 
"len" is used before intialization. Problem occurs on both i386 and amd64 
platforms.

>How-To-Repeat:
Try to compile kernel with "options IPFIREWALL". Here is one of the kernel 
configs with which the problem occurred:


cpu HAMMER
ident   BETA

#makeoptionsDEBUG=-g# Build kernel with gdb(1) debug symbols

options SCHED_ULE   # ULE scheduler
options PREEMPTION  # Enable kernel thread preemption
options INET# InterNETworking
#optionsINET6   # IPv6 communications protocols
#optionsSCTP# Stream Control Transmission Protocol
options FFS # Berkeley Fast Filesystem
options SOFTUPDATES # Enable FFS soft updates support
#optionsUFS_ACL # Support for access control lists
options UFS_DIRHASH # Improve performance on big directories
#optionsUFS_GJOURNAL# Enable gjournal-based UFS journaling
#optionsMD_ROOT # MD is a potential root device
#optionsNFSCL   # New Network Filesystem Client
#optionsNFSD# New Network Filesystem Server
#optionsNFSLOCKD# Network Lock Manager
#optionsNFS_ROOT# NFS usable as /, requires NFSCL
#optionsMSDOSFS # MSDOS Filesystem
#optionsCD9660  # ISO 9660 Filesystem
options PROCFS  # Process filesystem (requires PSEUDOFS)
options PSEUDOFS# Pseudo-filesystem framework
options GEOM_PART_GPT   # GUID Partition Tables.
options GEOM_LABEL  # Provides labelization
#optionsCOMPAT_FREEBSD32# Compatible with i386 binaries
#optionsCOMPAT_FREEBSD4 # Compatible with FreeBSD4
#optionsCOMPAT_FREEBSD5 # Compatible with FreeBSD5
#optionsCOMPAT_FREEBSD6 # Compatible with FreeBSD6
#optionsCOMPAT_FREEBSD7 # Compatible with FreeBSD7
options SCSI_DELAY=5000 # Delay (in ms) before probing SCSI
#optionsKTRACE  # ktrace(1) support
#optionsSTACK   # stack(9) support
options SYSVSHM # SYSV-style shared memory
options SYSVMSG # SYSV-style message queues
options SYSVSEM # SYSV-style semaphores
options _KPOSIX_PRIORITY_SCHEDULING # POSIX P1003_1B real-time 
extensions
options PRINTF_BUFR_SIZE=128# Prevent printf output being 
interspersed.
options KBD_INSTALL_CDEV# install a CDEV entry in /dev
#optionsHWPMC_HOOKS # Necessary kernel hooks for hwpmc(4)
#optionsAUDIT   # Security event auditing
#optionsMAC # TrustedBSD MAC Framework
##options   KDTRACE_FRAME   # Ensure frames are compiled in
##options   KDTRACE_HOOKS   # Kernel DTrace hooks
#optionsINCLUDE_CONFIG_FILE # Include this file in kernel

# Debugging for use in -current
#optionsKDB # Enable kernel debugger support.
#optionsDDB # Support DDB.
#optionsGDB # Support remote GDB.
#optionsDEADLKRES   # Enable the deadlock resolver
#optionsINVARIANTS  # Enable calls of extra sanity checking
#optionsINVARIANT_SUPPORT   # Extra sanity checks of internal 
structures, required by IN
VARIANTS
#optionsWITNESS # Enable checks to detect deadlocks and 
cycles
#optionsWITNESS_SKIPSPIN# Don't run witness on spinlocks for 
speed
#optionsMALLOC_DEBUG_MAXZONES=8 # Separate malloc(9) zones

# Make an SMP-capable kernel by default
options SMP # Symmetric MultiProcessor Kernel

# CPU frequency control
device  cpufreq

# Bus support.
device  acpi
device  pci

# Floppy drives
#device fdc

# ATA controllers
device  ahci# AHCI-compatible SA

Re: kern/142999: [puc] [patch] add support for the I-O DATA RSA-PCI2/R

2011-10-15 Thread eadler 
Synopsis: [puc] [patch] add support for the I-O DATA RSA-PCI2/R

State-Changed-From-To: open->patched
State-Changed-By: eadler
State-Changed-When: Sat Oct 15 21:06:53 UTC 2011
State-Changed-Why: 
committed in head

http://www.freebsd.org/cgi/query-pr.cgi?pr=142999
___
freebsd-bugs@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"

Re: kern/142999: commit references a PR

2011-10-15 Thread dfilter service 
The following reply was made to PR kern/142999; it has been noted by GNATS.

From: dfil...@freebsd.org (dfilter service)
To: bug-follo...@freebsd.org
Cc:  
Subject: Re: kern/142999: commit references a PR
Date: Sat, 15 Oct 2011 21:06:17 + (UTC)

 Author: eadler (ports committer)
 Date: Sat Oct 15 21:06:08 2011
 New Revision: 226404
 URL: http://svn.freebsd.org/changeset/base/226404
 
 Log:
   - add support for I-O DATA RSA-PCI2/R
   
   PR:  kern/142999
   Submitted by:Takefu Kenji 
   Approved by: jhb
   Approved by: sahil (mentor)
   MFC after:   1 week
 
 Modified:
   head/sys/dev/puc/pucdata.c
 
 Modified: head/sys/dev/puc/pucdata.c
 ==
 --- head/sys/dev/puc/pucdata.c Sat Oct 15 19:08:22 2011(r226403)
 +++ head/sys/dev/puc/pucdata.c Sat Oct 15 21:06:08 2011(r226404)
 @@ -645,6 +645,12 @@ const struct puc_cfg puc_pci_devices[] =
 * As sold by Kouwell http://www.kouwell.com/>.
 * I/O Flex PCI I/O Card Model-223 with 4 serial and 1 parallel ports.
 */
 +  {
 +  0x1415, 0x9501, 0x10fc ,0xc070,
 +  "I-O DATA RSA-PCI2/R",
 +  DEFAULT_RCLK * 8,
 +  PUC_PORT_2S, 0x10, 0, 8,
 +  },
  
{   0x1415, 0x9501, 0x131f, 0x2050,
"SIIG Cyber 4 PCI 16550",
 ___
 svn-src-...@freebsd.org mailing list
 http://lists.freebsd.org/mailman/listinfo/svn-src-all
 To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
 
___
freebsd-bugs@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"

Re: kern/43716: [puc] [patch] puc driver does not recognize Lava Dual-650 serial cards.

2011-10-15 Thread eadler 
Synopsis: [puc] [patch] puc driver does not recognize Lava Dual-650 serial 
cards.

Responsible-Changed-From-To: freebsd-bugs->eadler
Responsible-Changed-By: eadler
Responsible-Changed-When: Sat Oct 15 21:39:48 UTC 2011
Responsible-Changed-Why: 
Not my field, but I'll nag someone about these PRS

http://www.freebsd.org/cgi/query-pr.cgi?pr=43716
___
freebsd-bugs@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"

Re: kern/103250: [puc] puc failed to attach sio ports when loaded as module (NetMos NM9835)

2011-10-15 Thread eadler 
Synopsis: [puc] puc failed to attach sio ports when loaded as module (NetMos 
NM9835)

Responsible-Changed-From-To: freebsd-bugs->eadler
Responsible-Changed-By: eadler
Responsible-Changed-When: Sat Oct 15 21:39:50 UTC 2011
Responsible-Changed-Why: 
Not my field, but I'll nag someone about these PRS

http://www.freebsd.org/cgi/query-pr.cgi?pr=103250
___
freebsd-bugs@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"

Re: kern/132271: [puc] [patch] puc support for a generic card

2011-10-15 Thread eadler 
Synopsis: [puc] [patch] puc support for a generic card

Responsible-Changed-From-To: freebsd-bugs->eadler
Responsible-Changed-By: eadler
Responsible-Changed-When: Sat Oct 15 21:39:53 UTC 2011
Responsible-Changed-Why: 
Not my field, but I'll nag someone about these PRS

http://www.freebsd.org/cgi/query-pr.cgi?pr=132271
___
freebsd-bugs@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"

Re: kern/137436: [puc] [patch] Fix puc driver to support newer Timedia serial card (4027)

2011-10-15 Thread eadler 
Synopsis: [puc] [patch] Fix puc driver to support newer Timedia serial card 
(4027)

Responsible-Changed-From-To: freebsd-bugs->eadler
Responsible-Changed-By: eadler
Responsible-Changed-When: Sat Oct 15 21:39:55 UTC 2011
Responsible-Changed-Why: 
Not my field, but I'll nag someone about these PRS

http://www.freebsd.org/cgi/query-pr.cgi?pr=137436
___
freebsd-bugs@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"

Re: kern/151365: [puc] [patch] Two new Moxa puc(4) devices

2011-10-15 Thread eadler 
Synopsis: [puc] [patch] Two new Moxa puc(4) devices

Responsible-Changed-From-To: freebsd-bugs->eadler
Responsible-Changed-By: eadler
Responsible-Changed-When: Sat Oct 15 21:39:58 UTC 2011
Responsible-Changed-Why: 
Not my field, but I'll nag someone about these PRS

http://www.freebsd.org/cgi/query-pr.cgi?pr=151365
___
freebsd-bugs@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"

Re: kern/159669: [puc] [patch] Add Moxa CP-112UL support to puc(4)

2011-10-15 Thread eadler 
Synopsis: [puc] [patch] Add Moxa CP-112UL support to puc(4)

Responsible-Changed-From-To: freebsd-bugs->eadler
Responsible-Changed-By: eadler
Responsible-Changed-When: Sat Oct 15 21:40:01 UTC 2011
Responsible-Changed-Why: 
Not my field, but I'll nag someone about these PRS

http://www.freebsd.org/cgi/query-pr.cgi?pr=159669
___
freebsd-bugs@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"

Re: kern/142999: [puc] [patch] add support for the I-O DATA RSA-PCI2/R

2011-10-15 Thread eadler 
Synopsis: [puc] [patch] add support for the I-O DATA RSA-PCI2/R

Responsible-Changed-From-To: freebsd-bugs->eadler
Responsible-Changed-By: eadler
Responsible-Changed-When: Sat Oct 15 21:40:23 UTC 2011
Responsible-Changed-Why: 
I nagged, now I have to to take it

http://www.freebsd.org/cgi/query-pr.cgi?pr=142999
___
freebsd-bugs@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"

Re: kern/161692: Error in IPFW code halts kernel compile in 9.0-BETA3

2011-10-15 Thread Brett Glass 
The following reply was made to PR kern/161692; it has been noted by GNATS.

From: Brett Glass 
To: bug-follo...@freebsd.org
Cc:  
Subject: Re: kern/161692: Error in IPFW code halts kernel compile in
  9.0-BETA3
Date: Sat, 15 Oct 2011 16:05:26 -0600

 Additional notes:
 
 It appears that to make this bug crop up, the kernel option 
 IPFIREWALL_FORWARD must be set, along with the option IPFIREWALL.
 
 As a temporary workaround, I have added an assignment which sets 
 the variable "len" unconditionally to zero immediately after its 
 definition. However, since I do not know the code well, someone who 
 is more familiar with the code should make sure that this does not 
 mask a serious bug.
 
___
freebsd-bugs@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"