date:20130502

Re: Last current shows strange CAM/SCSI error on empty USB card reader on the boot

2013-05-02 Thread Alexander Motin

Thank you for the report. It is known issue. Steven (the author) is 
already testing the solution.


On 02.05.2013 09:51, Andrey Chernov wrote:

umass0:  on 
usbus3
umass0:  SCSI over Bulk-Only; quirks = 0x4100
umass0:10:0:-1: Attached to scbus10
da0 at umass-sim0 bus 0 scbus10 target 0 lun 0
da0:  Removable Direct Access SCSI-0 device
da0: 40.000MB/s transfers
da0: Attempt to query device size failed: NOT READY, Medium not present
(da0:umass-sim0:0:0:0): ATA COMMAND PASS THROUGH(16). CDB: 85 08 0a 00 00 02 00 
00 00 00 00 00 00 40 ec 00
(da0:umass-sim0:0:0:0): CAM status: SCSI Status Error
(da0:umass-sim0:0:0:0): SCSI status: Check Condition
(da0:umass-sim0:0:0:0): SCSI sense: NOT READY asc:3a,0 (Medium not present)
(da0:umass-sim0:0:0:0): Error 6, Unretryable error
(da0:umass-sim0:0:0:0): ATA COMMAND PASS THROUGH(16). CDB: 85 08 0a 00 00 02 00 
00 00 00 00 00 00 40 ec 00
(da0:umass-sim0:0:0:0): CAM status: SCSI Status Error
(da0:umass-sim0:0:0:0): SCSI status: Check Condition
(da0:umass-sim0:0:0:0): SCSI sense: NOT READY asc:3a,0 (Medium not present)
(da0:umass-sim0:0:0:0): Error 6, Unretryable error
(da0:umass-sim0:0:0:0): ATA COMMAND PASS THROUGH(16). CDB: 85 08 0a 00 00 02 00 
00 00 00 00 00 00 40 ec 00
(da0:umass-sim0:0:0:0): CAM status: SCSI Status Error
(da0:umass-sim0:0:0:0): SCSI status: Check Condition
(da0:umass-sim0:0:0:0): SCSI sense: NOT READY asc:3a,0 (Medium not present)
(da0:umass-sim0:0:0:0): Error 6, Unretryable error
(da0:umass-sim0:0:0:0): ATA COMMAND PASS THROUGH(16). CDB: 85 08 0a 00 00 02 00 
00 00 00 00 00 00 40 ec 00
(da0:umass-sim0:0:0:0): CAM status: SCSI Status Error
(da0:umass-sim0:0:0:0): SCSI status: Check Condition
(da0:umass-sim0:0:0:0): SCSI sense: NOT READY asc:3a,0 (Medium not present)
(da0:umass-sim0:0:0:0): Error 6, Unretryable error


--
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"

LOR: two vfs_bio.c:3070, ufs_dirhash.c:284 and vfs_mount.c:851, vfs_subr.c:2167

2013-05-02 Thread Ian FREISLICH

Hi

I'm getting these two LORs at boot time, they don't seem to be known
on http://ipv4.sources.zabbadoz.net/freebsd/lor.html

lock order reversal:
 1st 0xff83e37ee938 bufwait (bufwait) @ /usr/src/sys/kern/vfs_bio.c:3070
 2nd 0xfe0030283800 dirhash (dirhash) @ 
/usr/src/sys/ufs/ufs/ufs_dirhash.c:284
KDB: stack backtrace:
db_trace_self_wrapper() at db_trace_self_wrapper+0x2a/frame 0xff846b756410
_witness_debugger() at _witness_debugger+0x65/frame 0xff846b756430
witness_checkorder() at witness_checkorder+0x857/frame 0xff846b7564e0
_sx_xlock() at _sx_xlock+0x6e/frame 0xff846b756510
ufsdirhash_acquire() at ufsdirhash_acquire+0x33/frame 0xff846b756530
ufsdirhash_add() at ufsdirhash_add+0x19/frame 0xff846b756560
ufs_direnter() at ufs_direnter+0x976/frame 0xff846b756630
ufs_makeinode() at ufs_makeinode+0x296/frame 0xff846b7567f0
VOP_CREATE_APV() at VOP_CREATE_APV+0x8c/frame 0xff846b756820
vn_open_cred() at vn_open_cred+0x2da/frame 0xff846b756970
kern_openat() at kern_openat+0x1de/frame 0xff846b756ad0
amd64_syscall() at amd64_syscall+0x26c/frame 0xff846b756bf0
Xfast_syscall() at Xfast_syscall+0xf7/frame 0xff846b756bf0
--- syscall (5, FreeBSD ELF64, sys_open), rip = 0x800b6f99a, rsp = 0x7fffd84

lock order reversal:
 1st 0xfe003082f068 ufs (ufs) @ /usr/src/sys/kern/vfs_mount.c:851
 2nd 0xfe032a133240 devfs (devfs) @ /usr/src/sys/kern/vfs_subr.c:2167
KDB: stack backtrace:
db_trace_self_wrapper() at db_trace_self_wrapper+0x2a/frame 0xff846b408410
_witness_debugger() at _witness_debugger+0x65/frame 0xff846b408430
witness_checkorder() at witness_checkorder+0x857/frame 0xff846b4084e0
__lockmgr_args() at __lockmgr_args+0xda4/frame 0xff846b4085b0
vop_stdlock() at vop_stdlock+0x39/frame 0xff846b4085d0
VOP_LOCK1_APV() at VOP_LOCK1_APV+0x97/frame 0xff846b408600
_vn_lock() at _vn_lock+0x5e/frame 0xff846b408680
vget() at vget+0x63/frame 0xff846b4086d0
devfs_allocv() at devfs_allocv+0x13c/frame 0xff846b408730
devfs_root() at devfs_root+0x4d/frame 0xff846b408770
vfs_donmount() at vfs_donmount+0xa55/frame 0xff846b408a90
sys_nmount() at sys_nmount+0x6d/frame 0xff846b408ad0
amd64_syscall() at amd64_syscall+0x26c/frame 0xff846b408bf0
Xfast_syscall() at Xfast_syscall+0xf7/frame 0xff846b408bf0
--- syscall (378, FreeBSD ELF64, sys_nmount), rip = 0x800a96daa, rsp = 
0x7fffccc8, rbp = 0x7fffcce0 ---

Ian

-- 
Ian Freislich
___
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: panic: in_pcblookup_local (?)

2013-05-02 Thread Robert N. M. Watson

On 2 May 2013, at 01:57, Glen Barber wrote:

> So, I am admittedly not too familiar with DDB.  In fact, I just now
> realize the kernel is built without DDB...

DDB is a very powerful tool in that it's been custom-developed to help debug 
common kernel panics. It lacks some of the flexibility, and especially the 
data-type awareness of GDB, but GDB is a less well-suited tool when 
investigating common crash patterns. I'll usually start out debugging in DDB, 
and find that 90% of my in-development panics can be debugged with it, 
resorting to GDB for post-mortem analyses in production or particularly hard 
debugging cases (usually where DDB's pretty printers for data types fall 
short). I've wanted, for a long time, to teach DDB how to pretty-print 
arbitrary types using DTrace's CTF meta-data, which would address the most 
significant major case where I turn to GDB. Mind you, the limitations I see in 
GDB are made up for in most part by John's GDB scripts :-).

>> Put those in a dir and do 'source gdb6'.  You can then run 'ps' to get a 
>> good 
>> ps listing that includes threads.  You can also use 'thread apply all bt' to 
>> get stacktraces of all threads in kgdb.  I believe there is an 'allpcpu' 
>> command that is similar to 'show allpcpu' in DDB.
> 
> I have the outputs of 'ps', 'allpcpu', and 'thread apply all bt' saved
> to separate script(1) files.  Is there anything in particular I can look
> for before uploading the files somewhere public?  At quick-ish look
> though, I did not see anything cf-agent (the current process at time of
> panic) related.

To be honest, it's probably easiest if I just take a look at it and see what I 
see. In as much as I find interesting things, I'll follow up explaining what 
they are. We may find we can't track this problem down from the data we have -- 
but it's worth a try.

Robert
___
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: Kernel build error in hwpmc with system GNU cc

2013-05-02 Thread Davide Italiano

On Thu, May 2, 2013 at 8:43 AM, Andrey Chernov  wrote:
> cc1: warnings being treated as errors
> /usr/src/sys/modules/hwpmc/../../dev/hwpmc/hwpmc_core.c: In function 
> 'iap_allocate_pmc':
> /usr/src/sys/modules/hwpmc/../../dev/hwpmc/hwpmc_core.c:1935: warning: 'map' 
> may be used uninitialized in this function
> *** [hwpmc_core.o] Error code 1
>
> --
> bitcoin:13fGiNutKNHcVSsgtGQ7bQ5kgUKgEQHn7N

You can find a patch attached at the end of this mail that should fix
the problem.
More generally speaking, why are you building -CURRENT using GCC while
the default compiler has been clang since November 2012?
I understand we cannot completely get rid of GCC as long as
Tier-2/Tier-3 arch haven't full support for clang and friends, OTOH, I
see clang default on amd64 so I guess at some point we should declare
GCC not officially supported anymore. Putting the additional burden of
testing on the committer because two compilers are supported at the
same time doesn't scale really well, at least according to me.

Index: sys/dev/hwpmc/hwpmc_core.c
===
--- sys/dev/hwpmc/hwpmc_core.c  (revision 250174)
+++ sys/dev/hwpmc/hwpmc_core.c  (working copy)
@@ -1945,7 +1945,7 @@
caps = a->pm_caps;
if ((IAP_PMC_CAPS & caps) != caps)
return (EPERM);
-
+   map = 0;/* XXX: silent GCC warning */
arch = iap_is_event_architectural(pm->pm_event, &map);
if (arch == EV_IS_ARCH_NOTSUPP)
return (EOPNOTSUPP);

-- 
Davide

"There are no solved problems; there are only problems that are more
or less solved" -- Henri Poincare
___
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: panic: in_pcblookup_local (?)

2013-05-02 Thread Glen Barber

On Thu, May 02, 2013 at 10:27:39AM +0100, Robert N. M. Watson wrote:
> 
> On 2 May 2013, at 01:57, Glen Barber wrote:
> 
> > So, I am admittedly not too familiar with DDB.  In fact, I just now
> > realize the kernel is built without DDB...
> 
> DDB is a very powerful tool in that it's been custom-developed
> to help debug common kernel panics. It lacks some of the flexibility,
> and especially the data-type awareness of GDB, but GDB is a less
> well-suited tool when investigating common crash patterns. I'll
> usually start out debugging in DDB, and find that 90% of my
> in-development panics can be debugged with it, resorting to GDB for
> post-mortem analyses in production or particularly hard debugging
> cases (usually where DDB's pretty printers for data types fall
> short). I've wanted, for a long time, to teach DDB how to pretty-print
> arbitrary types using DTrace's CTF meta-data, which would address
> the most significant major case where I turn to GDB. Mind you, the
> limitations I see in GDB are made up for in most part by John's GDB
> scripts :-).
> 

Hmm.  Perhaps it would be worthwhile for me to rebuild the current
kernel with DDB support.  It looks like the machine has panicked a few
times over the last two weeks or so, but based on the timestamps of the
crash dumps and nagios complaints, happened during the middle of the
night when I would not have really noticed, or otherwise would have just
blamed my ISP.

Two of the panics are ath(4) related.  One looks similar to the one
referenced in this thread, similarly triggered by a CFEngine process.

In that case, the backtrace looks like:

#4 0x808cdbb3 at calltrap+0x8
#5 0x807371d8 at in_pcb_lport+0x128
#6 0x8073745a at in_pcbbind_setup+0x16a
#7 0x80737d8e at in_pcbconnect_setup+0x71e
#8 0x80737df9 at in_pcbconnect_mbuf+0x59
#9 0x807bf29f at udp_connect+0x11f
#10 0x80680615 at kern_connectat+0x275

Regarding DDB though, it would be rather difficult to access the machine
if it drops to a DDB debugger session, since the machine acts as my
firewall.

> >> Put those in a dir and do 'source gdb6'.  You can then run 'ps' to get a 
> >> good 
> >> ps listing that includes threads.  You can also use 'thread apply all bt' 
> >> to 
> >> get stacktraces of all threads in kgdb.  I believe there is an 'allpcpu' 
> >> command that is similar to 'show allpcpu' in DDB.
> > 
> > I have the outputs of 'ps', 'allpcpu', and 'thread apply all bt' saved
> > to separate script(1) files.  Is there anything in particular I can look
> > for before uploading the files somewhere public?  At quick-ish look
> > though, I did not see anything cf-agent (the current process at time of
> > panic) related.
> 
> To be honest, it's probably easiest if I just take a look at it
> and see what I see. In as much as I find interesting things, I'll
> follow up explaining what they are. We may find we can't track this
> problem down from the data we have -- but it's worth a try.
> 

Sure.  The files are available here:

https://www.glenbarber.us/stuff/in_pcblookup_local/vmcore.4.ps.txt
https://www.glenbarber.us/stuff/in_pcblookup_local/vmcore.4.allpcpu.txt

https://www.glenbarber.us/stuff/in_pcblookup_local/vmcore.4.thread_apply_all_bt.txt

Thanks to both of you for looking into this.

Glen



pgpAoAdObxR0p.pgp
Description: PGP signature

Re: panic: in_pcblookup_local (?)

2013-05-02 Thread Robert N. M. Watson


On 2 May 2013, at 11:42, Glen Barber wrote:

> Hmm.  Perhaps it would be worthwhile for me to rebuild the current
> kernel with DDB support.  It looks like the machine has panicked a few
> times over the last two weeks or so, but based on the timestamps of the
> crash dumps and nagios complaints, happened during the middle of the
> night when I would not have really noticed, or otherwise would have just
> blamed my ISP.
> 
> Two of the panics are ath(4) related.  One looks similar to the one
> referenced in this thread, similarly triggered by a CFEngine process.
> 
> In that case, the backtrace looks like:
> 
> #4 0x808cdbb3 at calltrap+0x8
> #5 0x807371d8 at in_pcb_lport+0x128
> #6 0x8073745a at in_pcbbind_setup+0x16a
> #7 0x80737d8e at in_pcbconnect_setup+0x71e
> #8 0x80737df9 at in_pcbconnect_mbuf+0x59
> #9 0x807bf29f at udp_connect+0x11f
> #10 0x80680615 at kern_connectat+0x275
> 
> Regarding DDB though, it would be rather difficult to access the machine
> if it drops to a DDB debugger session, since the machine acts as my
> firewall.

Thanks -- will take a look at the attached.

FWIW, though, I'm worried by the number of panics you are seeing, especially 
given that they involve multiple subsystems, and in particular, John's 
observation about a potentially corrupted pointer. This makes me wonder whether 
(a) you are experiencing hardware faults -- it would be worth running some 
memory/cpu/etc tests and (b) if we might be seeing a software memory corruption 
bug of some sort.

Robert
___
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: Last current shows strange CAM/SCSI error on empty USB card reader on the boot

2013-05-02 Thread Steven Hartland


Yer, this one is slightly different issue than the one ken@ reported
but its easy fixed, just needs:-
Index: sys/cam/scsi/scsi_da.c
===
--- sys/cam/scsi/scsi_da.c  (revision 250174)
+++ sys/cam/scsi/scsi_da.c  (working copy)
@@ -3118,7 +3183,7 @@
   } else {
   int error;
   error = daerror(done_ccb, CAM_RETRY_SELTO,
-   SF_RETRY_UA|SF_QUIET_IR);
+   SF_RETRY_UA|SF_NO_PRINT);
   if (error == ERESTART)
   return;

Will include in the patches once they been approved.

- Original Message - 
From: "Alexander Motin" 


Thank you for the report. It is known issue. Steven (the author) is 
already testing the solution.


On 02.05.2013 09:51, Andrey Chernov wrote:

umass0:  on 
usbus3
umass0:  SCSI over Bulk-Only; quirks = 0x4100
umass0:10:0:-1: Attached to scbus10
da0 at umass-sim0 bus 0 scbus10 target 0 lun 0
da0:  Removable Direct Access SCSI-0 device
da0: 40.000MB/s transfers
da0: Attempt to query device size failed: NOT READY, Medium not present
(da0:umass-sim0:0:0:0): ATA COMMAND PASS THROUGH(16). CDB: 85 08 0a 00 00 02 00 
00 00 00 00 00 00 40 ec 00
(da0:umass-sim0:0:0:0): CAM status: SCSI Status Error
(da0:umass-sim0:0:0:0): SCSI status: Check Condition
(da0:umass-sim0:0:0:0): SCSI sense: NOT READY asc:3a,0 (Medium not present)
(da0:umass-sim0:0:0:0): Error 6, Unretryable error
(da0:umass-sim0:0:0:0): ATA COMMAND PASS THROUGH(16). CDB: 85 08 0a 00 00 02 00 
00 00 00 00 00 00 40 ec 00
(da0:umass-sim0:0:0:0): CAM status: SCSI Status Error
(da0:umass-sim0:0:0:0): SCSI status: Check Condition
(da0:umass-sim0:0:0:0): SCSI sense: NOT READY asc:3a,0 (Medium not present)
(da0:umass-sim0:0:0:0): Error 6, Unretryable error
(da0:umass-sim0:0:0:0): ATA COMMAND PASS THROUGH(16). CDB: 85 08 0a 00 00 02 00 
00 00 00 00 00 00 40 ec 00
(da0:umass-sim0:0:0:0): CAM status: SCSI Status Error
(da0:umass-sim0:0:0:0): SCSI status: Check Condition
(da0:umass-sim0:0:0:0): SCSI sense: NOT READY asc:3a,0 (Medium not present)
(da0:umass-sim0:0:0:0): Error 6, Unretryable error
(da0:umass-sim0:0:0:0): ATA COMMAND PASS THROUGH(16). CDB: 85 08 0a 00 00 02 00 
00 00 00 00 00 00 40 ec 00
(da0:umass-sim0:0:0:0): CAM status: SCSI Status Error
(da0:umass-sim0:0:0:0): SCSI status: Check Condition
(da0:umass-sim0:0:0:0): SCSI sense: NOT READY asc:3a,0 (Medium not present)
(da0:umass-sim0:0:0:0): Error 6, Unretryable error



This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. 


In the event of misdirection, illegible or incomplete transmission please 
telephone +44 845 868 1337
or return the E.mail to postmas...@multiplay.co.uk.

___
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: panic: in_pcblookup_local (?)

2013-05-02 Thread Glen Barber

On Thu, May 02, 2013 at 12:25:08PM +0100, Robert N. M. Watson wrote:
> 
> On 2 May 2013, at 11:42, Glen Barber wrote:
> 
> > Hmm.  Perhaps it would be worthwhile for me to rebuild the current
> > kernel with DDB support.  It looks like the machine has panicked a few
> > times over the last two weeks or so, but based on the timestamps of the
> > crash dumps and nagios complaints, happened during the middle of the
> > night when I would not have really noticed, or otherwise would have just
> > blamed my ISP.
> > 
> > Two of the panics are ath(4) related.  One looks similar to the one
> > referenced in this thread, similarly triggered by a CFEngine process.
> > 
> > In that case, the backtrace looks like:
> > 
> > #4 0x808cdbb3 at calltrap+0x8
> > #5 0x807371d8 at in_pcb_lport+0x128
> > #6 0x8073745a at in_pcbbind_setup+0x16a
> > #7 0x80737d8e at in_pcbconnect_setup+0x71e
> > #8 0x80737df9 at in_pcbconnect_mbuf+0x59
> > #9 0x807bf29f at udp_connect+0x11f
> > #10 0x80680615 at kern_connectat+0x275
> > 
> > Regarding DDB though, it would be rather difficult to access the machine
> > if it drops to a DDB debugger session, since the machine acts as my
> > firewall.
> 
> Thanks -- will take a look at the attached.
> 
> FWIW, though, I'm worried by the number of panics you are seeing,
> especially given that they involve multiple subsystems, and in
> particular, John's observation about a potentially corrupted pointer.
> This makes me wonder whether (a) you are experiencing hardware
> faults -- it would be worth running some memory/cpu/etc tests and
> (b) if we might be seeing a software memory corruption bug of some
> sort.
> 

I will run memtest this weekend, once I move some wires around so I do
not lose internet access entirely.  I'll run some stress tests that do
not require the machine to be offline in the meantime.

I certainly won't discount hardware issue being the cause.

For what it is worth, I just looked through my svn commit logs for that
machine's configuration, and the only relatively recent change that was
made was enabling powerd(8) - but that was about 3 months ago.

Glen



pgpJKiZ5dteTa.pgp
Description: PGP signature

Re: Light humour

2013-05-02 Thread David Demelier

2013/4/28 Paul Webster :
> Just got this link on IRC, (freenode/##freebsd) was so funny I thought
> I would see if I could get any of you guys to spit out you're coffee
> :)
>
> http://antibsd.wordpress.com/

Do not post any comment on that website ! The user will replace any
content you write by something like "You're article is excellent,
pointing exactly the facts".

All of the comments are probably edited by the maintainer

--
Demelier David
___
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"

Google Summer of Code 2013

2013-05-02 Thread Gavin Atkinson

Hi all,

A reminder: The deadline for applications is 19:00 UTC Friday May 3rd
(tomorrow).

FreeBSD is pleased to announce that once again we have been selected to
participate in the Google Summer of Code program.  This gives University
students the opportunity to earn a $5000 USD stipend in exchange for
working on Open Source software over their Summer break.  Students have
around 12 weeks to work on their project, and will be mentored by
existing FreeBSD committers.  Participating organisations will earn $500
USD per student mentored.  Over the past eight years we have hosted over
150 successful projects, and look forward to continuing this trend.

FreeBSD's organisation page may be found at
http://www.google-melange.com/gsoc/org/google/gsoc2013/freebsd and a
list of possible project ideas may be found at
https://wiki.freebsd.org/IdeasPage .  Please note that projects do not
have to come from the ideas list, and indeed students are encouraged to
produce their own project ideas - the majority of past projects have
been thought up by the particpants themselves.  We are encouraging
discussion of projects on the freebsd-hackers mailing list and the
#freebsd-soc IRC channel on EFNet.

Students are also encouraged to visit http://www.google-melange.com/ to
view more details of the program, including eligibility requirements,
and a list of other participating organisations.

If you have administrative questions you can contact the FreeBSD GSoC
administration team at soc-adm...@freebsd.org.

Thanks,

Gavin


signature.asc
Description: This is a digitally signed message part

Re: Kernel build error in hwpmc with system GNU cc

2013-05-02 Thread Dimitry Andric


On 2013-05-02 12:06, Davide Italiano wrote:

On Thu, May 2, 2013 at 8:43 AM, Andrey Chernov  wrote:

cc1: warnings being treated as errors
/usr/src/sys/modules/hwpmc/../../dev/hwpmc/hwpmc_core.c: In function 
'iap_allocate_pmc':
/usr/src/sys/modules/hwpmc/../../dev/hwpmc/hwpmc_core.c:1935: warning: 'map' 
may be used uninitialized in this function

...

You can find a patch attached at the end of this mail that should fix
the problem.


Hm, the warning seems to be bogus.  Newer versions of gcc (I tried 4.7.3
and 4.8.1) do not warn about 'map' (though they both warn about another
variable, which is set, but not used.)



More generally speaking, why are you building -CURRENT using GCC while
the default compiler has been clang since November 2012?
I understand we cannot completely get rid of GCC as long as
Tier-2/Tier-3 arch haven't full support for clang and friends, OTOH, I
see clang default on amd64 so I guess at some point we should declare
GCC not officially supported anymore. Putting the additional burden of
testing on the committer because two compilers are supported at the
same time doesn't scale really well, at least according to me.


Some people still prefer gcc, and while this warning is a bit annoying,
I see no problem in putting in a workaround.  Using gcc for arches which
default to clang will most likely have to be supported for quite some
time.

Also, if the external toolchain support ever comes off the ground, it
will probably become necessary to suppress certain warnings on an
individual basis; for example, with recent gcc versions, there are quite
a large number of "variable x set but not used" warnings, which are not
very useful, most of the time.
___
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"

Current r250174 repeatable panic

2013-05-02 Thread Andrey Smagin

Today current paniced after some minutes of network load. Kernel conf is 
GENERIC with added ROUTETABLES=16 option. Screenshoots 
http://vvtlan.ru/panic1.jpg http://vvtlan.ru/panic2.jpg .
___
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: Light humour

2013-05-02 Thread Eitan Adler

On 2 May 2013 08:21, David Demelier  wrote:
> 2013/4/28 Paul Webster :
>> Just got this link on IRC, (freenode/##freebsd) was so funny I thought
>> I would see if I could get any of you guys to spit out you're coffee
>> :)
>>
>> http://antibsd.wordpress.com/
>
> Do not post any comment on that website ! The user will replace any
> content you write by something like "You're article is excellent,
> pointing exactly the facts".
>
> All of the comments are probably edited by the maintainer
>
https://gs1.wac.edgecastcdn.net/8019B6/data.tumblr.com/tumblr_lmpcbtar6f1qafrh6.jpg

-- 
Eitan Adler
___
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: Kernel build error in hwpmc with system GNU cc

2013-05-02 Thread Davide Italiano

On Thu, May 2, 2013 at 3:10 PM, Dimitry Andric  wrote:
> On 2013-05-02 12:06, Davide Italiano wrote:
>>
>> On Thu, May 2, 2013 at 8:43 AM, Andrey Chernov  wrote:
>>>
>>> cc1: warnings being treated as errors
>>> /usr/src/sys/modules/hwpmc/../../dev/hwpmc/hwpmc_core.c: In function
>>> 'iap_allocate_pmc':
>>> /usr/src/sys/modules/hwpmc/../../dev/hwpmc/hwpmc_core.c:1935: warning:
>>> 'map' may be used uninitialized in this function
>
> ...
>
>> You can find a patch attached at the end of this mail that should fix
>> the problem.
>
>
> Hm, the warning seems to be bogus.  Newer versions of gcc (I tried 4.7.3
> and 4.8.1) do not warn about 'map' (though they both warn about another
> variable, which is set, but not used.)
>
>
>
>> More generally speaking, why are you building -CURRENT using GCC while
>> the default compiler has been clang since November 2012?
>> I understand we cannot completely get rid of GCC as long as
>> Tier-2/Tier-3 arch haven't full support for clang and friends, OTOH, I
>> see clang default on amd64 so I guess at some point we should declare
>> GCC not officially supported anymore. Putting the additional burden of
>> testing on the committer because two compilers are supported at the
>> same time doesn't scale really well, at least according to me.
>
>
> Some people still prefer gcc, and while this warning is a bit annoying,
> I see no problem in putting in a workaround.  Using gcc for arches which

Yes, for sure it's not a problem. I try to run 'make universe' when I
commit change, but it's already slow on relatively recent hardware,
and I just found annoying the need of rebuilding the system using two
different compilers (in particular if one of them generates warning
that are bogus, as happened in this case). Other than being
time-expensive, the switch at runtime from clang to GCC was not so
easy for me. In fact, if I try to change from clang to gcc46 and run
'make buildkernel' I get some errors like:

cc1: error: unrecognized command line option '-fformat-extensions'
cc1: warning: unrecognized command line option
"-Wno-error-parentheses-equality" [enabled by default]
cc1: warning: unrecognized command line option "-Wno-error-empty-body"
[enabled by default]
cc1: warning: unrecognized command line option
"-Wno-error-tautological-compare" [enabled by default]
*** [genassym.o] Error code 1

which disappear actually if I re-run buildworld. Maybe I'm missing
something or I'm doing something wrong. But, at the end of the day, I
preferred to have my lazyness winning. Actually, I don't think it
worth the effort.
If there's an easier way to do this, feel free to point me to it.

> default to clang will most likely have to be supported for quite some
> time.
>
> Also, if the external toolchain support ever comes off the ground, it
> will probably become necessary to suppress certain warnings on an
> individual basis; for example, with recent gcc versions, there are quite
> a large number of "variable x set but not used" warnings, which are not
> very useful, most of the time.

Thanks,

-- 
Davide

"There are no solved problems; there are only problems that are more
or less solved" -- Henri Poincare
___
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: Kernel build error in hwpmc with system GNU cc

2013-05-02 Thread Andrey Chernov

On 02.05.2013 14:06, Davide Italiano wrote:
>> /usr/src/sys/modules/hwpmc/../../dev/hwpmc/hwpmc_core.c:1935: warning: 'map' 
>> may be used uninitialized in this function
>> *** [hwpmc_core.o] Error code 1

> You can find a patch attached at the end of this mail that should fix
> the problem.

Thanks, it fix this warning.

> More generally speaking, why are you building -CURRENT using GCC while
> the default compiler has been clang since November 2012?

1) clang is not ready for production, it is too buggy. See its fixes
rate for very common things 'must work' in every compiler. It is
included into -current not because of its quality, but to involve
developers into clang bugfixes to make its progress faster, and
personally me don't want to find clang bugs.

2) Its build time is too long.

3) It generates bigger code.

> Putting the additional burden of
> testing on the committer because two compilers are supported at the
> same time doesn't scale really well, at least according to me.

You'll hit this error later in any case, attempting to MFC your changes
to -stable with GNU cc.

-- 
bitcoin:13fGiNutKNHcVSsgtGQ7bQ5kgUKgEQHn7N
___
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: Last current shows strange CAM/SCSI error on empty USB card reader on the boot

2013-05-02 Thread Andrey Chernov

On 02.05.2013 15:33, Steven Hartland wrote:
> Yer, this one is slightly different issue than the one ken@ reported
> but its easy fixed, just needs:-
> Index: sys/cam/scsi/scsi_da.c
> ===
> --- sys/cam/scsi/scsi_da.c  (revision 250174)
> +++ sys/cam/scsi/scsi_da.c  (working copy)
> @@ -3118,7 +3183,7 @@
>} else {
>int error;
>error = daerror(done_ccb, CAM_RETRY_SELTO,
> -   SF_RETRY_UA|SF_QUIET_IR);
> +   SF_RETRY_UA|SF_NO_PRINT);
>if (error == ERESTART)
>return;
> 

Thanx, this patch suppress console error.

-- 
bitcoin:13fGiNutKNHcVSsgtGQ7bQ5kgUKgEQHn7N
___
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: Kernel build error in hwpmc with system GNU cc

2013-05-02 Thread Davide Italiano

On Thu, May 2, 2013 at 3:42 PM, Andrey Chernov  wrote:
> On 02.05.2013 14:06, Davide Italiano wrote:
>>> /usr/src/sys/modules/hwpmc/../../dev/hwpmc/hwpmc_core.c:1935: warning: 
>>> 'map' may be used uninitialized in this function
>>> *** [hwpmc_core.o] Error code 1
>
>> You can find a patch attached at the end of this mail that should fix
>> the problem.
>
> Thanks, it fix this warning.
>
>> More generally speaking, why are you building -CURRENT using GCC while
>> the default compiler has been clang since November 2012?
>
> 1) clang is not ready for production, it is too buggy. See its fixes
> rate for very common things 'must work' in every compiler. It is
> included into -current not because of its quality, but to involve
> developers into clang bugfixes to make its progress faster, and
> personally me don't want to find clang bugs.
>
> 2) Its build time is too long.
>
> 3) It generates bigger code.
>
>> Putting the additional burden of
>> testing on the committer because two compilers are supported at the
>> same time doesn't scale really well, at least according to me.
>
> You'll hit this error later in any case, attempting to MFC your changes
> to -stable with GNU cc.
>
> --
> bitcoin:13fGiNutKNHcVSsgtGQ7bQ5kgUKgEQHn7N

I won't object about your 2) and 3), but if you fear to hit bugs you
shouldn't probably run -CURRENT.
About the backport, I faced the problem of adapting code in the past
when merging to stable releases, so this is actually a different
problem. If I'd blindly merged the incrimined change to 9-STABLE
without building and notifying the GCC warning, then I would expect
you ranting at me because of build failure.
There's a notion of "default compiler" in 9 and in 10 and they're
different. My opinion is that people should live with it, and unless
someone will introduce some mechanism a-la redports.org to overcome
the issue, I will take my risks committing changes and fixing failures
if they occur. It's already really difficult to have tinderbox not
ranting these days, adding another compiler just result in another
dimension of complexity in the whole scenario.

Thanks,

-- 
Davide

"There are no solved problems; there are only problems that are more
or less solved" -- Henri Poincare
___
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: Last current shows strange CAM/SCSI error on empty USB card reader on the boot

2013-05-02 Thread Steven Hartland


r250181 should fix this Andrey:-
http://svnweb.freebsd.org/changeset/base/250181

   Regards
   Steve
- Original Message - 
From: "Alexander Motin" 


Thank you for the report. It is known issue. Steven (the author) is 
already testing the solution.


On 02.05.2013 09:51, Andrey Chernov wrote:

umass0:  on 
usbus3
umass0:  SCSI over Bulk-Only; quirks = 0x4100
umass0:10:0:-1: Attached to scbus10
da0 at umass-sim0 bus 0 scbus10 target 0 lun 0
da0:  Removable Direct Access SCSI-0 device
da0: 40.000MB/s transfers
da0: Attempt to query device size failed: NOT READY, Medium not present
(da0:umass-sim0:0:0:0): ATA COMMAND PASS THROUGH(16). CDB: 85 08 0a 00 00 02 00 
00 00 00 00 00 00 40 ec 00
(da0:umass-sim0:0:0:0): CAM status: SCSI Status Error
(da0:umass-sim0:0:0:0): SCSI status: Check Condition
(da0:umass-sim0:0:0:0): SCSI sense: NOT READY asc:3a,0 (Medium not present)
(da0:umass-sim0:0:0:0): Error 6, Unretryable error
(da0:umass-sim0:0:0:0): ATA COMMAND PASS THROUGH(16). CDB: 85 08 0a 00 00 02 00 
00 00 00 00 00 00 40 ec 00
(da0:umass-sim0:0:0:0): CAM status: SCSI Status Error
(da0:umass-sim0:0:0:0): SCSI status: Check Condition
(da0:umass-sim0:0:0:0): SCSI sense: NOT READY asc:3a,0 (Medium not present)
(da0:umass-sim0:0:0:0): Error 6, Unretryable error
(da0:umass-sim0:0:0:0): ATA COMMAND PASS THROUGH(16). CDB: 85 08 0a 00 00 02 00 
00 00 00 00 00 00 40 ec 00
(da0:umass-sim0:0:0:0): CAM status: SCSI Status Error
(da0:umass-sim0:0:0:0): SCSI status: Check Condition
(da0:umass-sim0:0:0:0): SCSI sense: NOT READY asc:3a,0 (Medium not present)
(da0:umass-sim0:0:0:0): Error 6, Unretryable error
(da0:umass-sim0:0:0:0): ATA COMMAND PASS THROUGH(16). CDB: 85 08 0a 00 00 02 00 
00 00 00 00 00 00 40 ec 00
(da0:umass-sim0:0:0:0): CAM status: SCSI Status Error
(da0:umass-sim0:0:0:0): SCSI status: Check Condition
(da0:umass-sim0:0:0:0): SCSI sense: NOT READY asc:3a,0 (Medium not present)
(da0:umass-sim0:0:0:0): Error 6, Unretryable error


--
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"




This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. 


In the event of misdirection, illegible or incomplete transmission please 
telephone +44 845 868 1337
or return the E.mail to postmas...@multiplay.co.uk.

___
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"

files disappearing from ls on NFS

2013-05-02 Thread Hartmut Brandt


Hi,

I've updated one of my -current machines this week (previous update was in 
february). Now I see a strange effect (it seems only on NFS mounts): ls or 
even echo * will list only some files (strange enough the first files from 
the normal, alphabetically ordered list). If I change something in the 
directory (delete a file or create a new one) for some time the complete 
listing will appear but after sime time (seconds to a minute or so) again 
only part of the files is listed.


A ktrace on ls /usr/src/lib/libc/gen shows that getdirentries is called 
only once (returning 4096). For a full listing getdirentries is called 5 
times with the last returning 0.


I can still open files that are not listed if I know their name, though.

The NFS server is a Windows 2008 server with an OpenText NFS Server which 
works without problems to all the other FreeBSD machines.


So what could that be?

Regards,
harti
___
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: files disappearing from ls on NFS

2013-05-02 Thread Freddie Cash

There was just a security update that dealt with changes to getdirent or
something along those lines.

Check the security notices, and then see if reverting that change makes a
difference.

It was just in the past week here.


On Thu, May 2, 2013 at 9:11 AM, Hartmut Brandt wrote:

> Hi,
>
> I've updated one of my -current machines this week (previous update was in
> february). Now I see a strange effect (it seems only on NFS mounts): ls or
> even echo * will list only some files (strange enough the first files from
> the normal, alphabetically ordered list). If I change something in the
> directory (delete a file or create a new one) for some time the complete
> listing will appear but after sime time (seconds to a minute or so) again
> only part of the files is listed.
>
> A ktrace on ls /usr/src/lib/libc/gen shows that getdirentries is called
> only once (returning 4096). For a full listing getdirentries is called 5
> times with the last returning 0.
>
> I can still open files that are not listed if I know their name, though.
>
> The NFS server is a Windows 2008 server with an OpenText NFS Server which
> works without problems to all the other FreeBSD machines.
>
> So what could that be?
>
> Regards,
> harti
> __**_
> freebsd-current@freebsd.org mailing list
> http://lists.freebsd.org/**mailman/listinfo/freebsd-**current
> To unsubscribe, send any mail to "freebsd-current-unsubscribe@**
> freebsd.org "
>



-- 
Freddie Cash
fjwc...@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: panic: in_pcblookup_local (?)

2013-05-02 Thread John Baldwin

On Thursday, May 02, 2013 5:27:39 am Robert N. M. Watson wrote:
> 
> On 2 May 2013, at 01:57, Glen Barber wrote:
> 
> > So, I am admittedly not too familiar with DDB.  In fact, I just now
> > realize the kernel is built without DDB...
> 
> DDB is a very powerful tool in that it's been custom-developed to help debug 
> common kernel panics. It lacks some of the flexibility, and especially the 
> data-type awareness 
of GDB, but GDB is a less well-suited tool when investigating common crash 
patterns. I'll usually start out debugging in DDB, and find that 90% of my 
in-development panics 
can be debugged with it, resorting to GDB for post-mortem analyses in 
production or particularly hard debugging cases (usually where DDB's pretty 
printers for data types fall 
short). I've wanted, for a long time, to teach DDB how to pretty-print 
arbitrary types using DTrace's CTF meta-data, which would address the most 
significant major case where 
I turn to GDB. Mind you, the limitations I see in GDB are made up for in most 
part by John's GDB scripts :-).

Heh, I prefer DDB for active development as well, but after being forced to
work in an environment where I had to largely do post-mortem analysis, I had
to get a gdb environment that was close to as functional.  Also, using kgdb
on a live system to obtain info is less invasive than ddb (doesn't halt the
system), and you can easily add new scripts to generate useful reports without
having to recompile or reboot.

-- 
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: panic: in_pcblookup_local (?)

2013-05-02 Thread John Baldwin

On Thursday, May 02, 2013 7:25:08 am Robert N. M. Watson wrote:
> 
> On 2 May 2013, at 11:42, Glen Barber wrote:
> 
> > Hmm.  Perhaps it would be worthwhile for me to rebuild the current
> > kernel with DDB support.  It looks like the machine has panicked a few
> > times over the last two weeks or so, but based on the timestamps of the
> > crash dumps and nagios complaints, happened during the middle of the
> > night when I would not have really noticed, or otherwise would have just
> > blamed my ISP.
> > 
> > Two of the panics are ath(4) related.  One looks similar to the one
> > referenced in this thread, similarly triggered by a CFEngine process.
> > 
> > In that case, the backtrace looks like:
> > 
> > #4 0x808cdbb3 at calltrap+0x8
> > #5 0x807371d8 at in_pcb_lport+0x128
> > #6 0x8073745a at in_pcbbind_setup+0x16a
> > #7 0x80737d8e at in_pcbconnect_setup+0x71e
> > #8 0x80737df9 at in_pcbconnect_mbuf+0x59
> > #9 0x807bf29f at udp_connect+0x11f
> > #10 0x80680615 at kern_connectat+0x275
> > 
> > Regarding DDB though, it would be rather difficult to access the machine
> > if it drops to a DDB debugger session, since the machine acts as my
> > firewall.
> 
> Thanks -- will take a look at the attached.
> 
> FWIW, though, I'm worried by the number of panics you are seeing, especially 
given that they involve multiple subsystems, and in particular, John's 
observation about a potentially corrupted pointer. This makes me wonder 
whether (a) you are experiencing hardware faults -- it would be worth running 
some memory/cpu/etc tests and (b) if we might be seeing a software memory 
corruption bug of some sort.

Other users have reported this (Ian Lepore), and Peter Wemm can now reproduce
these at will as well, so I think this is a software bug.  What might be 
easiest if we can't figure this out from the crashdump is just to bisect the
offending revision.

-- 
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: LOR: two vfs_bio.c:3070, ufs_dirhash.c:284 and vfs_mount.c:851, vfs_subr.c:2167

2013-05-02 Thread John Baldwin

On Thursday, May 02, 2013 3:55:25 am Ian FREISLICH wrote:
> Hi
> 
> I'm getting these two LORs at boot time, they don't seem to be known
> on http://ipv4.sources.zabbadoz.net/freebsd/lor.html
> 
> lock order reversal:
>  1st 0xff83e37ee938 bufwait (bufwait) @ /usr/src/sys/kern/vfs_bio.c:3070
>  2nd 0xfe0030283800 dirhash (dirhash) @ 
/usr/src/sys/ufs/ufs/ufs_dirhash.c:284
> KDB: stack backtrace:
> db_trace_self_wrapper() at db_trace_self_wrapper+0x2a/frame 
0xff846b756410
> _witness_debugger() at _witness_debugger+0x65/frame 0xff846b756430
> witness_checkorder() at witness_checkorder+0x857/frame 0xff846b7564e0
> _sx_xlock() at _sx_xlock+0x6e/frame 0xff846b756510
> ufsdirhash_acquire() at ufsdirhash_acquire+0x33/frame 0xff846b756530
> ufsdirhash_add() at ufsdirhash_add+0x19/frame 0xff846b756560
> ufs_direnter() at ufs_direnter+0x976/frame 0xff846b756630
> ufs_makeinode() at ufs_makeinode+0x296/frame 0xff846b7567f0
> VOP_CREATE_APV() at VOP_CREATE_APV+0x8c/frame 0xff846b756820
> vn_open_cred() at vn_open_cred+0x2da/frame 0xff846b756970
> kern_openat() at kern_openat+0x1de/frame 0xff846b756ad0
> amd64_syscall() at amd64_syscall+0x26c/frame 0xff846b756bf0
> Xfast_syscall() at Xfast_syscall+0xf7/frame 0xff846b756bf0
> --- syscall (5, FreeBSD ELF64, sys_open), rip = 0x800b6f99a, rsp = 
0x7fffd84
> 
> lock order reversal:
>  1st 0xfe003082f068 ufs (ufs) @ /usr/src/sys/kern/vfs_mount.c:851
>  2nd 0xfe032a133240 devfs (devfs) @ /usr/src/sys/kern/vfs_subr.c:2167
> KDB: stack backtrace:
> db_trace_self_wrapper() at db_trace_self_wrapper+0x2a/frame 
0xff846b408410
> _witness_debugger() at _witness_debugger+0x65/frame 0xff846b408430
> witness_checkorder() at witness_checkorder+0x857/frame 0xff846b4084e0
> __lockmgr_args() at __lockmgr_args+0xda4/frame 0xff846b4085b0
> vop_stdlock() at vop_stdlock+0x39/frame 0xff846b4085d0
> VOP_LOCK1_APV() at VOP_LOCK1_APV+0x97/frame 0xff846b408600
> _vn_lock() at _vn_lock+0x5e/frame 0xff846b408680
> vget() at vget+0x63/frame 0xff846b4086d0
> devfs_allocv() at devfs_allocv+0x13c/frame 0xff846b408730
> devfs_root() at devfs_root+0x4d/frame 0xff846b408770
> vfs_donmount() at vfs_donmount+0xa55/frame 0xff846b408a90
> sys_nmount() at sys_nmount+0x6d/frame 0xff846b408ad0
> amd64_syscall() at amd64_syscall+0x26c/frame 0xff846b408bf0
> Xfast_syscall() at Xfast_syscall+0xf7/frame 0xff846b408bf0
> --- syscall (378, FreeBSD ELF64, sys_nmount), rip = 0x800a96daa, rsp = 
0x7fffccc8, rbp = 0x7fffcce0 ---

The are both old and known.  The bufwait one is documented in ufs_dirhash.c
and is a false positive.

-- 
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: files disappearing from ls on NFS

2013-05-02 Thread Hartmut Brandt

On Thu, 2 May 2013, Freddie Cash wrote:

FC>There was just a security update that dealt with changes to getdirent or
FC>something along those lines.
FC>
FC>Check the security notices, and then see if reverting that change makes a
FC>difference.
FC>
FC>It was just in the past week here.

If you mean SA-13:05.nfsserver that seams to be related to the NFS server 
only. My problem is in the client.

harti

FC>
FC>
FC>On Thu, May 2, 2013 at 9:11 AM, Hartmut Brandt 
FC>wrote:
FC>  Hi,
FC>
FC>  I've updated one of my -current machines this week (previous
FC>  update was in february). Now I see a strange effect (it seems
FC>  only on NFS mounts): ls or even echo * will list only some files
FC>  (strange enough the first files from the normal, alphabetically
FC>  ordered list). If I change something in the directory (delete a
FC>  file or create a new one) for some time the complete listing
FC>  will appear but after sime time (seconds to a minute or so)
FC>  again only part of the files is listed.
FC>
FC>  A ktrace on ls /usr/src/lib/libc/gen shows that getdirentries is
FC>  called only once (returning 4096). For a full listing
FC>  getdirentries is called 5 times with the last returning 0.
FC>
FC>  I can still open files that are not listed if I know their name,
FC>  though.
FC>
FC>  The NFS server is a Windows 2008 server with an OpenText NFS
FC>  Server which works without problems to all the other FreeBSD
FC>  machines.
FC>
FC>  So what could that be?
FC>
FC>  Regards,
FC>  harti
FC>  ___
FC>  freebsd-current@freebsd.org mailing list
FC>  http://lists.freebsd.org/mailman/listinfo/freebsd-current
FC>  To unsubscribe, send any mail to
FC>  "freebsd-current-unsubscr...@freebsd.org"
FC>
FC>
FC>
FC>
FC>--
FC>Freddie Cash
FC>fjwc...@gmail.com
FC>
FC>
___
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: panic: in_pcblookup_local (?)

2013-05-02 Thread Ian FREISLICH

John Baldwin wrote:
> On Thursday, May 02, 2013 7:25:08 am Robert N. M. Watson wrote:
> > 
> > On 2 May 2013, at 11:42, Glen Barber wrote:
> > 
> > > Hmm.  Perhaps it would be worthwhile for me to rebuild the current
> > > kernel with DDB support.  It looks like the machine has panicked a few
> > > times over the last two weeks or so, but based on the timestamps of the
> > > crash dumps and nagios complaints, happened during the middle of the
> > > night when I would not have really noticed, or otherwise would have just
> > > blamed my ISP.
> > > 
> > > Two of the panics are ath(4) related.  One looks similar to the one
> > > referenced in this thread, similarly triggered by a CFEngine process.
> > > 
> > > In that case, the backtrace looks like:
> > > 
> > > #4 0x808cdbb3 at calltrap+0x8
> > > #5 0x807371d8 at in_pcb_lport+0x128
> > > #6 0x8073745a at in_pcbbind_setup+0x16a
> > > #7 0x80737d8e at in_pcbconnect_setup+0x71e
> > > #8 0x80737df9 at in_pcbconnect_mbuf+0x59
> > > #9 0x807bf29f at udp_connect+0x11f
> > > #10 0x80680615 at kern_connectat+0x275
> > > 
> > > Regarding DDB though, it would be rather difficult to access the machine
> > > if it drops to a DDB debugger session, since the machine acts as my
> > > firewall.
> > 
> > Thanks -- will take a look at the attached.
> > 
> > FWIW, though, I'm worried by the number of panics you are seeing, especiall
y 
> given that they involve multiple subsystems, and in particular, John's 
> observation about a potentially corrupted pointer. This makes me wonder 
> whether (a) you are experiencing hardware faults -- it would be worth running
 
> some memory/cpu/etc tests and (b) if we might be seeing a software memory 
> corruption bug of some sort.
> 
> Other users have reported this (Ian Lepore), and Peter Wemm can now reproduce
> these at will as well, so I think this is a software bug.  What might be 
> easiest if we can't figure this out from the crashdump is just to bisect the
> offending revision.

I've started a binary search.  I'll let you know what that turns up.

Ian

-- 
Ian Freislich
___
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: Kernel build error in hwpmc with system GNU cc

2013-05-02 Thread Konstantin Belousov

On Thu, May 02, 2013 at 04:12:36PM +0200, Davide Italiano wrote:
> On Thu, May 2, 2013 at 3:42 PM, Andrey Chernov  wrote:
> > On 02.05.2013 14:06, Davide Italiano wrote:
> >>> /usr/src/sys/modules/hwpmc/../../dev/hwpmc/hwpmc_core.c:1935: warning: 
> >>> 'map' may be used uninitialized in this function
> >>> *** [hwpmc_core.o] Error code 1
> >
> >> You can find a patch attached at the end of this mail that should fix
> >> the problem.
> >
> > Thanks, it fix this warning.
> >
> >> More generally speaking, why are you building -CURRENT using GCC while
> >> the default compiler has been clang since November 2012?
> >
> > 1) clang is not ready for production, it is too buggy. See its fixes
> > rate for very common things 'must work' in every compiler. It is
> > included into -current not because of its quality, but to involve
> > developers into clang bugfixes to make its progress faster, and
> > personally me don't want to find clang bugs.
> >
> > 2) Its build time is too long.
> >
> > 3) It generates bigger code.
> >
> >> Putting the additional burden of
> >> testing on the committer because two compilers are supported at the
> >> same time doesn't scale really well, at least according to me.
> >
> > You'll hit this error later in any case, attempting to MFC your changes
> > to -stable with GNU cc.
> >
> > --
> > bitcoin:13fGiNutKNHcVSsgtGQ7bQ5kgUKgEQHn7N
> 
> 
> I won't object about your 2) and 3), but if you fear to hit bugs you
> shouldn't probably run -CURRENT.
> About the backport, I faced the problem of adapting code in the past
> when merging to stable releases, so this is actually a different
> problem. If I'd blindly merged the incrimined change to 9-STABLE
> without building and notifying the GCC warning, then I would expect
> you ranting at me because of build failure.
> There's a notion of "default compiler" in 9 and in 10 and they're
> different. My opinion is that people should live with it, and unless
> someone will introduce some mechanism a-la redports.org to overcome
> the issue, I will take my risks committing changes and fixing failures
> if they occur. It's already really difficult to have tinderbox not
> ranting these days, adding another compiler just result in another
> dimension of complexity in the whole scenario.

I experienced the same issues e.g. with the TTM commit, on somewhat
bigger scale. There were 3 or 4 problems compiling the code with gcc,
which were silently accepted by clang. Most ridiculous was clang silence
on the double-declaration of the functions.

For myself, I decided after the episode that I am morally unblended if
default build is fine after the commit. For any compile issues reported
by users with non-default compilers, I obviously take a look and do fix
if possible, but I certainly do not intend to even try to test with
non-default compiler on my own.


pgpgM0TT1cB8I.pgp
Description: PGP signature

Re: Current r250174 repeatable panic

2013-05-02 Thread David Wolfskill

On Thu, May 02, 2013 at 05:10:43PM +0400, Andrey Smagin wrote:
> Today current paniced after some minutes of network load. Kernel conf is 
> GENERIC with added ROUTETABLES=16 option. Screenshoots 
> http://vvtlan.ru/panic1.jpg http://vvtlan.ru/panic2.jpg .
> ...

I was able to build & boot:

FreeBSD g1-227.catwhisker.org 10.0-CURRENT FreeBSD 10.0-CURRENT #888  
r250173M/250174:132: Thu May  2 10:02:50 PDT 2013 
r...@g1-227.catwhisker.org:/usr/obj/usr/src/sys/CANARY  i386

without any issues (that I could see).  On my laptop, this included
running xdm with x11/nvidia-driver, logging in to X11, and starting a
handful of xterms and logging in (via ssh) to several machines.

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
Taliban: Evil men with guns afraid of truth from a 14-year old girl.

See http://www.catwhisker.org/~david/publickey.gpg for my public key.

pgpGQIvLHUfP_.pgp
Description: PGP signature

buildworld of HEAD failing under 8.1-RELEASE

2013-05-02 Thread Ryan Stone

I am getting the following error when trying to build HEAD on an
8.1-RELEASE build machine (i386 jail on an amd64 host):

===> lib/clang/libllvmanalysis (all)
/usr/d2/users/rstone/git/svos/lib/clang/libllvmanalysis/../../../contrib/llvm/lib/Analysis/ConstantFolding.cpp:
In function 'llvm::Constant* llvm::ConstantFoldCall(llvm::Function*,
llvm::ArrayRef, const llvm::TargetLibraryInfo*)':
/usr/d2/users/rstone/git/svos/lib/clang/libllvmanalysis/../../../contrib/llvm/lib/Analysis/ConstantFolding.cpp:1310:
error: 'log2' was not declared in this scope
*** [ConstantFolding.o] Error code 1
1 error
*** [all] Error code 2
1 error
*** [cross-tools] Error code 2
1 error
*** [_cross-tools] Error code 2
1 error
*** Error code 2
1 error

Is there anything that I can do other than build on another machine?  I
don't control the build machines at $WORK so I'm not sure whether I can get
them upgraded. :(
___
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: panic: in_pcblookup_local (?)

2013-05-02 Thread John Baldwin

On Thursday, May 02, 2013 1:53:47 pm Ian FREISLICH wrote:
> John Baldwin wrote:
> > On Thursday, May 02, 2013 7:25:08 am Robert N. M. Watson wrote:
> > > 
> > > On 2 May 2013, at 11:42, Glen Barber wrote:
> > > 
> > > > Hmm.  Perhaps it would be worthwhile for me to rebuild the current
> > > > kernel with DDB support.  It looks like the machine has panicked a few
> > > > times over the last two weeks or so, but based on the timestamps of the
> > > > crash dumps and nagios complaints, happened during the middle of the
> > > > night when I would not have really noticed, or otherwise would have just
> > > > blamed my ISP.
> > > > 
> > > > Two of the panics are ath(4) related.  One looks similar to the one
> > > > referenced in this thread, similarly triggered by a CFEngine process.
> > > > 
> > > > In that case, the backtrace looks like:
> > > > 
> > > > #4 0x808cdbb3 at calltrap+0x8
> > > > #5 0x807371d8 at in_pcb_lport+0x128
> > > > #6 0x8073745a at in_pcbbind_setup+0x16a
> > > > #7 0x80737d8e at in_pcbconnect_setup+0x71e
> > > > #8 0x80737df9 at in_pcbconnect_mbuf+0x59
> > > > #9 0x807bf29f at udp_connect+0x11f
> > > > #10 0x80680615 at kern_connectat+0x275
> > > > 
> > > > Regarding DDB though, it would be rather difficult to access the machine
> > > > if it drops to a DDB debugger session, since the machine acts as my
> > > > firewall.
> > > 
> > > Thanks -- will take a look at the attached.
> > > 
> > > FWIW, though, I'm worried by the number of panics you are seeing, 
> > > especiall
> y 
> > given that they involve multiple subsystems, and in particular, John's 
> > observation about a potentially corrupted pointer. This makes me wonder 
> > whether (a) you are experiencing hardware faults -- it would be worth 
> > running
>  
> > some memory/cpu/etc tests and (b) if we might be seeing a software memory 
> > corruption bug of some sort.
> > 
> > Other users have reported this (Ian Lepore), and Peter Wemm can now 
> > reproduce
> > these at will as well, so I think this is a software bug.  What might be 
> > easiest if we can't figure this out from the crashdump is just to bisect the
> > offending revision.
> 
> I've started a binary search.  I'll let you know what that turns up.

Thanks, and sorry for getting my Ian's mixed up. :-/

-- 
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: buildworld of HEAD failing under 8.1-RELEASE

2013-05-02 Thread Nikolai Lifanov

On 05/02/2013 02:28 PM, Ryan Stone wrote:
> I am getting the following error when trying to build HEAD on an
> 8.1-RELEASE build machine (i386 jail on an amd64 host):
> 
> ===> lib/clang/libllvmanalysis (all)
> /usr/d2/users/rstone/git/svos/lib/clang/libllvmanalysis/../../../contrib/llvm/lib/Analysis/ConstantFolding.cpp:
> In function 'llvm::Constant* llvm::ConstantFoldCall(llvm::Function*,
> llvm::ArrayRef, const llvm::TargetLibraryInfo*)':
> /usr/d2/users/rstone/git/svos/lib/clang/libllvmanalysis/../../../contrib/llvm/lib/Analysis/ConstantFolding.cpp:1310:
> error: 'log2' was not declared in this scope
> *** [ConstantFolding.o] Error code 1
> 1 error
> *** [all] Error code 2
> 1 error
> *** [cross-tools] Error code 2
> 1 error
> *** [_cross-tools] Error code 2
> 1 error
> *** Error code 2
> 1 error
> 
> Is there anything that I can do other than build on another machine?  I
> don't control the build machines at $WORK so I'm not sure whether I can get
> them upgraded. :(
> ___
> 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"
> 

I think, per http://svnweb.freebsd.org/base/head/UPDATING?view=co
You need to bootstrap clang by building a recent version WITHOUT_CLANG
and then removing the version.

- Nikolai Lifanov

___
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"

No ATA disks on 9.1

2013-05-02 Thread Alex Keda


see begin in:
http://lists.freebsd.org/pipermail/freebsd-current/2012-November/038000.html

today, I have time and try find problem commit for 9-stable

2012.05.04.15.20.00 - all work OK
2012.05.05.00.00.00 - cannot boot

it's only two kernel-related file for this period:
 Edit src/lib/libc/gen/sem_new.c
  Add delta 1.8.2.2 2012.05.04.20.45.53 jilles
 Edit src/sys/dev/pci/pci.c
  Add delta 1.425.2.8 2012.05.04.15.38.47 hselasky
 Edit src/sys/ufs/ufs/ufs_vnops.c
  Add delta 1.328.2.7 2012.05.04.15.51.23 jh


diff -Nru /usr/src/sys/dev/pci/pci.c /tmp/src/sys/dev/pci/pci.c
--- /usr/src/sys/dev/pci/pci.c  2013-05-03 00:05:19.0 +0400
+++ /tmp/src/sys/dev/pci/pci.c  2013-05-02 23:56:38.0 +0400
@@ -27,7 +27,7 @@
  */

 #include 
-__FBSDID("$FreeBSD: src/sys/dev/pci/pci.c,v 1.425.2.7 2012/04/11 
20:50:17 jhb Exp $");
+__FBSDID("$FreeBSD: src/sys/dev/pci/pci.c,v 1.425.2.8 2012/05/04 
15:38:47 hselasky Exp $");


 #include "opt_bus.h"

@@ -2746,16 +2746,15 @@
prefetch ? RF_PREFETCHABLE : 0);
if (res == NULL) {
/*
-* If the allocation fails, clear the BAR and delete
-* the resource list entry to force
-* pci_alloc_resource() to allocate resources from the
-* parent.
+* If the allocation fails, delete the resource list entry
+* to force pci_alloc_resource() to allocate resources
+* from the parent.
 */
resource_list_delete(rl, type, reg);
-   start = 0;
-   } else
+   } else {
start = rman_get_start(res);
-   pci_write_bar(dev, pm, start);
+   pci_write_bar(dev, pm, start);
+   }
return (barlen);
 }

@@ -3824,7 +3823,7 @@
if ((desc = malloc(strlen(vp) + strlen(dp) + 3, M_DEVBUF, 
M_NOWAIT)) !=

NULL)
sprintf(desc, "%s, %s", vp, dp);
- out:
+out:
if (vp != NULL)
free(vp, M_DEVBUF);
if (dp != NULL)
@@ -4100,7 +4099,7 @@
count, *rid, type, rman_get_start(res));
map = rman_get_start(res);
pci_write_bar(child, pm, map);
-out:;
+out:
return (res);
 }

@@ -4289,19 +4288,6 @@
type, rid, rman_get_start(rle->res));
return;
}
-
-#ifndef __PCI_BAR_ZERO_VALID
-   /*
-* If this is a BAR, clear the BAR so it stops
-* decoding before releasing the resource.
-*/
-   switch (type) {
-   case SYS_RES_IOPORT:
-   case SYS_RES_MEMORY:
-   pci_write_bar(child, pci_find_bar(child, rid), 0);
-   break;
-   }
-#endif
resource_list_unreserve(rl, dev, child, type, rid);
}
resource_list_delete(rl, type, rid);

diff -Nru /usr/src/sys/ufs/ufs/ufs_vnops.c /tmp/src/sys/ufs/ufs/ufs_vnops.c
--- /usr/src/sys/ufs/ufs/ufs_vnops.c2013-05-03 00:05:30.0 +0400
+++ /tmp/src/sys/ufs/ufs/ufs_vnops.c2013-05-02 23:56:49.0 +0400
@@ -35,7 +35,7 @@
  */

 #include 
-__FBSDID("$FreeBSD: src/sys/ufs/ufs/ufs_vnops.c,v 1.328.2.6 2012/05/02 
15:15:28 jh Exp $");
+__FBSDID("$FreeBSD: src/sys/ufs/ufs/ufs_vnops.c,v 1.328.2.7 2012/05/04 
15:51:23 jh Exp $");


 #include "opt_quota.h"
 #include "opt_suiddir.h"
@@ -528,6 +528,10 @@
return (EINVAL);
}
if (vap->va_flags != VNOVAL) {
+   if ((vap->va_flags & ~(UF_NODUMP | UF_IMMUTABLE | 
UF_APPEND |

+   UF_OPAQUE | UF_NOUNLINK | SF_ARCHIVED | SF_IMMUTABLE |
+   SF_APPEND | SF_NOUNLINK | SF_SNAPSHOT)) != 0)
+   return (EOPNOTSUPP);
if (vp->v_mount->mnt_flag & MNT_RDONLY)
return (EROFS);
/*
___
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: Virtualbox addition in FreeBSD -current guest OS?

2013-05-02 Thread Bernhard Fröhlich

This should be fixed together with the update to 4.2.12 now.

On Fri, Apr 26, 2013 at 7:43 PM, Mark Johnston  wrote:
> On Fri, Apr 26, 2013 at 11:07:35AM -0400, Glen Barber wrote:
>> On Fri, Apr 26, 2013 at 11:02:10AM -0400, Mark Johnston wrote:
>> > On Fri, Apr 26, 2013 at 10:49:55AM -0400, Glen Barber wrote:
>> > > On Fri, Apr 26, 2013 at 10:45:19AM -0400, Viren Shah wrote:
>> > > > I was having problems compiling the virtualbox guest additions  on a 
>> > > > FBSD
>> > > > -current  (Apr 23 20:30 EDT) system. I changed all the VM_OBJECT_LOCKs 
>> > > > to
>> > > > VM_OBJECT_WLOCKs (and same for the UNLOCKS) and added rwlock.h to the
>> > > > includes. That enabled it to compile but I'm having problems getting X
>> > > > started (it just hangs) using those vbox modules for xorg. Log msg (see
>> > > > attached) says "failed to initialize VirtualBox device (rc=-102)"
>> > > >
>> > > > Anyone having recently compiled the vbox ose-additions on a -current 
>> > > > system
>> > > > and had it work? I'm just trying to figure out if this is a
>> > > > -current-related issue or a vbox related one.
>> > > >
>> > >
>> > > This was fixed months ago, I think.  Is your ports tree updated?
>> >
>> > As far as the compilation issue goes, the virtualbox-ose-kmod port is
>> > indeed fixed but virtualbox-ose-additions is still broken on current
>> > with the latest ports tree.
>>
>> *sigh*...  Is this broken "again" or broken "still" ?
>
> Looks like the latter based on the port's revision history. It was just
> never fixed when the lock changed to a rwlock.
> ___
> 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"



-- 
Bernhard Froehlich
http://www.bluelife.at/
___
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: buildworld of HEAD failing under 8.1-RELEASE

2013-05-02 Thread Dimitry Andric

On May 2, 2013, at 20:28, Ryan Stone  wrote:
> I am getting the following error when trying to build HEAD on an
> 8.1-RELEASE build machine (i386 jail on an amd64 host):
> 
> ===> lib/clang/libllvmanalysis (all)
> /usr/d2/users/rstone/git/svos/lib/clang/libllvmanalysis/../../../contrib/llvm/lib/Analysis/ConstantFolding.cpp:
> In function 'llvm::Constant* llvm::ConstantFoldCall(llvm::Function*,
> llvm::ArrayRef, const llvm::TargetLibraryInfo*)':
> /usr/d2/users/rstone/git/svos/lib/clang/libllvmanalysis/../../../contrib/llvm/lib/Analysis/ConstantFolding.cpp:1310:
> error: 'log2' was not declared in this scope
...
> Is there anything that I can do other than build on another machine?  I
> don't control the build machines at $WORK so I'm not sure whether I can get
> them upgraded. :(

In 8.1-RELEASE, there was no log2() MFC yet.  Can you please try the attached 
diff?


llvm-config-log2-1.diff
Description: Binary data
___
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: buildworld of HEAD failing under 8.1-RELEASE

2013-05-02 Thread Ryan Stone

On Thu, May 2, 2013 at 7:02 PM, Dimitry Andric  wrote:

> On May 2, 2013, at 20:28, Ryan Stone  wrote:
> > I am getting the following error when trying to build HEAD on an
> > 8.1-RELEASE build machine (i386 jail on an amd64 host):
> >
> > ===> lib/clang/libllvmanalysis (all)
> >
> /usr/d2/users/rstone/git/svos/lib/clang/libllvmanalysis/../../../contrib/llvm/lib/Analysis/ConstantFolding.cpp:
> > In function 'llvm::Constant* llvm::ConstantFoldCall(llvm::Function*,
> > llvm::ArrayRef, const llvm::TargetLibraryInfo*)':
> >
> /usr/d2/users/rstone/git/svos/lib/clang/libllvmanalysis/../../../contrib/llvm/lib/Analysis/ConstantFolding.cpp:1310:
> > error: 'log2' was not declared in this scope
> ...
> > Is there anything that I can do other than build on another machine?  I
> > don't control the build machines at $WORK so I'm not sure whether I can
> get
> > them upgraded. :(
>
> In 8.1-RELEASE, there was no log2() MFC yet.  Can you please try the
> attached diff?
>

This fixed it.  Thank you.
___
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: Virtualbox addition in FreeBSD -current guest OS?

2013-05-02 Thread Glen Barber

On Fri, May 03, 2013 at 12:13:58AM +0200, Bernhard Fröhlich wrote:
> This should be fixed together with the update to 4.2.12 now.
> 

Thank you.

Glen



pgplW_7fUjT3v.pgp
Description: PGP signature

Re: No ATA disks on 9.1

2013-05-02 Thread Alex Keda


03.05.2013 00:18, Alex Keda пишет:

see begin in:
http://lists.freebsd.org/pipermail/freebsd-current/2012-November/038000.html


today, I have time and try find problem commit for 9-stable

2012.05.04.15.20.00 - all work OK
2012.05.05.00.00.00 - cannot boot



I try build after
> Edit src/sys/dev/pci/pci.c
>  Add delta 1.425.2.8 2012.05.04.15.38.47 hselasky
it's cannot boot

___
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: Last current shows strange CAM/SCSI error on empty USB card reader on the boot

LOR: two vfs_bio.c:3070, ufs_dirhash.c:284 and vfs_mount.c:851, vfs_subr.c:2167

Re: panic: in_pcblookup_local (?)

Re: Kernel build error in hwpmc with system GNU cc

Re: panic: in_pcblookup_local (?)

Re: panic: in_pcblookup_local (?)

Re: Last current shows strange CAM/SCSI error on empty USB card reader on the boot

Re: panic: in_pcblookup_local (?)

Re: Light humour

Google Summer of Code 2013

Re: Kernel build error in hwpmc with system GNU cc

Current r250174 repeatable panic

Re: Light humour

Re: Kernel build error in hwpmc with system GNU cc

Re: Kernel build error in hwpmc with system GNU cc

Re: Last current shows strange CAM/SCSI error on empty USB card reader on the boot

Re: Kernel build error in hwpmc with system GNU cc

Re: Last current shows strange CAM/SCSI error on empty USB card reader on the boot

files disappearing from ls on NFS

Re: files disappearing from ls on NFS

Re: panic: in_pcblookup_local (?)

Re: panic: in_pcblookup_local (?)

Re: LOR: two vfs_bio.c:3070, ufs_dirhash.c:284 and vfs_mount.c:851, vfs_subr.c:2167

Re: files disappearing from ls on NFS

Re: panic: in_pcblookup_local (?)

Re: Kernel build error in hwpmc with system GNU cc

Re: Current r250174 repeatable panic

buildworld of HEAD failing under 8.1-RELEASE

Re: panic: in_pcblookup_local (?)

Re: buildworld of HEAD failing under 8.1-RELEASE

No ATA disks on 9.1

Re: Virtualbox addition in FreeBSD -current guest OS?

Re: buildworld of HEAD failing under 8.1-RELEASE

Re: buildworld of HEAD failing under 8.1-RELEASE

Re: Virtualbox addition in FreeBSD -current guest OS?

Re: No ATA disks on 9.1

36 matches

Site Navigation

Mail list logo

Footer information