date:20120611

Re: Documenting ports options (was Re: Why Are You NOT Using FreeBSD ?)

2012-06-11 Thread Daniel Kalchev

On Jun 12, 2012, at 2:41 AM, grenville armitage wrote:

> 
> 
>> Rainer Duffner  writes:
>   [..]
>>> Personally, I don't need more frequent FreeBSD-releases but two or
>>> maybe three ports-tree freezes per year would be good.
> 
> Perhaps not so much freezes per se, but if there are particular
> dates at which the ports tree is known to compile properly (for
> some preferred definition of 'properly') those dates could be
> kept in a list somewhere, for people to use with the cvsup
> "date=" option?

I believe the reason this is not happening is that there is no date, when the 
ports tree does build all ports "just fine". Some of the ports are not 
compilable if you compile other ports, or select certain options in other ports 
as well.

For example, you might have a date, when KDE4 compiles and runs, just fine. But 
at the same date, you cannot say the same for say Gnome, or science/meep 
(random pick).

It is of course "doable". The reason nobody is doing it is because by the time 
you have "stable ports tree" lots of software in there and more importantly 
most of the mainstream software in there that sees active development is 
already out of date and sometimes with unattached security problems.

There is a fundamental misconception of what the ports tree is. This is not the 
"ready made" software, where you just user portmaster/portinstall to add new 
software or you go to the port's directory and type "make install".

The ports tree is a collection of instructions how to build foreign to FreeBSD 
software, plus the necessary infrastructure and few "common sense" options and 
that is it. If you view it any other way, you are in trouble.

The "pick and install software" functionality does not really exist in FreeBSD. 
The closest is to use packages and yet closer is the packaging system found in 
PC-BSD that uses the Apple style "fat app" approach.

It is more appropriate to view FreeBSD and ports as the tools to build your own 
"OS" (in the sense that most people understand it) with functionality, tuning 
and packages you need.

Of course, the ports system can be improved and is in fact, all the time.

Daniel___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

GCC-4.6-20120608 has a corrupt archive or a bad checksum

2012-06-11 Thread John Merryweather Cooper


Bad distfile or checksum for lang/gcc46

jmcooper@g7-HP$ sudo make checksum
Making GCC 4.6.4.20120608 for FreeBSD 9.0 target=x86_64-portbld-freebsd9.0
===>  License check disabled, port has not defined LICENSE
===>  Found saved configuration for gcc-4.6.4.20120608
=> SHA256 Checksum mismatch for gcc-4.6-20120608.tar.bz2.
=> SHA256 Checksum OK for ecj-4.5.jar.
===>  Refetch for 1 more times files: gcc-4.6-20120608.tar.bz2
Making GCC 4.6.4.20120608 for FreeBSD 9.0 target=x86_64-portbld-freebsd9.0
===>  License check disabled, port has not defined LICENSE
===>  Found saved configuration for gcc-4.6.4.20120608
=> gcc-4.6-20120608.tar.bz2 doesn't seem to exist in /usr/ports/distfiles/.
=> Attempting to fetch 
ftp://ftp-stud.fht-esslingen.de/pub/Mirrors/sources.redhat.com/gcc/snapshots/4.6-20120608/gcc-4.6-20120608.tar.bz2

Making GCC 4.6.4.20120608 for FreeBSD 9.0 target=x86_64-portbld-freebsd9.0
===>  License check disabled, port has not defined LICENSE
===>  Found saved configuration for gcc-4.6.4.20120608
=> SHA256 Checksum mismatch for gcc-4.6-20120608.tar.bz2.
=> SHA256 Checksum OK for ecj-4.5.jar.
===>  Giving up on fetching files: gcc-4.6-20120608.tar.bz2
Make sure the Makefile and distinfo file (/usr/ports/lang/gcc46/distinfo)
are up to date.  If you are absolutely sure you want to override this
check, type "make NO_CHECKSUM=yes [other args]".
*** [checksum] Error code 1

--
--
John M. Cooper

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

Re: Why Are You NOT Using FreeBSD ?

2012-06-11 Thread Chuck Swiger

Hi, Dave--

On Jun 11, 2012, at 4:35 PM, Dave Hayes wrote:
[ ... ]
> Do I have this wrong? Anyone see a problem with this picture?
> What can we do to "just upgrade" in a safe fashion when we want to? 

Two things help tremendously:

#1: Have working backups.  If you run into a problem, roll back the
system to a working state.  If you cannot restore a working system
easily, fix your backup solution until you can rollback easily.

#2: Have a package-building box and test builds before installing
new package builds to other boxes.  Your downtime for upgrades
to the rest of your boxes become minimized.

Regards,
-- 
-Chuck

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

Re: Why Are You NOT Using FreeBSD ?

2012-06-11 Thread Dave Hayes

Adam Strohl  writes:
> There in lies the question -- why do you need to compile a port which 
> was just released?   Is it a security thing or is it "I want the latest" 
> ?  I'm just curious (and totally uninterested in how this ranks in your 
> "worse question" list).

If I weren't honorable, I'd consider this question a troll. It's so far
afield from my daily reality...well I'm going to take this at face
value, because maybe -I've- got something wrong. ;)

Let's just consider Firefox, which has a rather aggressive release
schedule (once a month). 

 $ pkg_info -r firefox-10.0.3,1 | grep Dependency | wc -l
   175

Look at some of these dependencies:

 $ pkg_info -r firefox-10.0.3,1 | grep Dependency | sort
  ...
  Dependency: cairo-1.10.2_3,1
  ...
  Dependency: gtk-2.24.6
  ...
  Dependency: libgnome-2.32.0
  ...
  Dependency: perl-threaded-5.14.2_2
  ...
  Dependency: python27-2.7.2_4

Basically, everytime you want to upgrade firefox to 'stay current', you
are upgrading a fair number of heavyweight packages. The chances that
these will change month to month are high. (In the interests of brevity
I will leave the verification of this to interested parties). Any of the
ports listed above can have dependencies and consequences that reach
very far into your workflow. 

If you do not upgrade them, you risk that firefox breaks in unknown
ways. This is a rock and a hard place...do you upgrade everything from
scratch (safest, but the 48 hour downtime is not unreasonable) or do you
try to just replace that one port (risky, but you'll likely be up in an
hour)? 

For firefox, it might very well be a security thing that causes the
upgrade. Note well that I am not running 12 (is it at 12 now? 13? urgh.) 
because I'm in development and I do not want to touch certain other
ports. 

Do I have this wrong? Anyone see a problem with this picture?
What can we do to "just upgrade" in a safe fashion when we want to? 
-- 
Dave Hayes - Consultant - Altadena CA, USA - d...@jetcafe.org 
>>> The opinions expressed above are entirely my own <<<

The treasure house within you contains everything, and you
are free to use it. You don't need to seek outside.

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

Re: Documenting ports options (was Re: Why Are You NOT Using FreeBSD ?)

2012-06-11 Thread grenville armitage





Rainer Duffner  writes:

[..]

Personally, I don't need more frequent FreeBSD-releases but two or
maybe three ports-tree freezes per year would be good.


Perhaps not so much freezes per se, but if there are particular
dates at which the ports tree is known to compile properly (for
some preferred definition of 'properly') those dates could be
kept in a list somewhere, for people to use with the cvsup
"date=" option?

cheers,
gja

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

Documenting ports options (was Re: Why Are You NOT Using FreeBSD ?)

2012-06-11 Thread Dave Hayes

[ This probably should be redirected to freebsd-ports but I am not
  subscribed so the anal mailer will likely reject such a submission ]

Rainer Duffner  writes:
> Am 06.06.2012 um 20:59 schrieb Dave Hayes:
>> I believe this is the first time I've seen more documentation labeled as
>> "extraneous". :) I had thought to suggest an implementation by having a
>> simple pkg-option-desr file which describes the options and implications
>> in each port. Are you suggesting that such a file would be unwelcome? 
>> 
> No, but take a look at the nginx port, which (I'm too lazy to count)
> has gained a couple of dozens of options over the years.

This is a port I use often, and yes...it's a lot of work to document it.
It is good to read the nginx wiki to learn what these are and perhaps
any initial foray into documenting these options should merely be a set
of links, each one telling us where this option is discussed on the
nginx wiki. 

I had to go read the wiki too, and it's required reading if you do advanced
nginx work like I do. Still, it takes 5 minutes to add links to a text
file in the port eh? 

> Asking him to do even more work - I wouldn't dare to do that ;-)

So don't ask, just write some links. ;) 

> Sometimes, options only make sense in context of the selection of
> options of other ports and it thus may no be easily explainable in one
> line.

I don't understand Are you saying this is a reason not to document what
these options do?

> Personally, I don't need more frequent FreeBSD-releases but two or
> maybe three ports-tree freezes per year would be good.

While I have learned a bit more about ports by reading this and other
threads, I rarely worry about ports freezes. Production software in
ports is a moving target (security fixes, bug fixes, etc). I use 
portsnap a lot.
-- 
Dave Hayes - Consultant - Altadena CA, USA - d...@jetcafe.org 
>>> The opinions expressed above are entirely my own <<<

Exaggeration is a standard peculiarity of man. To deprecate
is often a form of exaggeration which people do not notice
because it appears to be its opposite.

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

Re: mpt: Unable to memory map registers

2012-06-11 Thread Andrey Zonov


On 6/12/12 12:19 AM, John Baldwin wrote:

On Monday, June 11, 2012 11:25:38 am Andrey Zonov wrote:

On 6/11/12 6:19 PM, John Baldwin wrote:

On Saturday, June 09, 2012 3:06:19 pm Andrey Zonov wrote:

On 6/9/12 9:35 PM, Marius Strobl wrote:

On Sat, Jun 09, 2012 at 12:58:05PM +0400, Andrey Zonov wrote:

On 6/8/12 10:27 PM, John Baldwin wrote:

On Friday, June 08, 2012 11:48:50 am Andrey Zonov wrote:

On Fri, Jun 8, 2012 at 7:19 PM, John Baldwin wrote:

On Friday, June 08, 2012 3:14:19 am Andrey Zonov wrote:

On 6/7/12 10:02 PM, Andrey Zonov wrote:

Hi,

I just upgraded a few machines from 8.2-STABLE (r221983) to 9.0-

STABLE

(r234600) and now they can't find any disk because SAS controller
cannot
initialize with the following diagnostic:

mpt0: port 0xd000-0xd0ff irq 26 at

device

3.0 on pci6
mpt0: 0x4000 bytes of rid 0x14 res 3 failed (0, 0x).
mpt0: Unable to memory map registers.
mpt0: Giving Up.

pciconf -lv:
mpt0@pci0:6:3:0: class=0x01 card=0x81dd1043 chip=0x00541000
rev=0x02
hdr=0x00
vendor = 'LSI Logic / Symbios Logic'
device = 'SAS1068 PCI-X Fusion-MPT SAS'
class = mass storage
subclass = SCSI

I tried to boot to latest HEAD and found the same problem. I also

tried

to build kernel with mpt driver from my 8.2. Controller didn't
initialize with the same diagnostic. So it looks like the problem is
not
in mpt driver.

Any help would be appreciated.



+jhb@

Hi John,

Could you please help me with the problem above?  It looks like the
problem is in PCI code and you changed things there.


Can you get a verbose dmesg?



Yes, it's in attach.


Can you get the output of 'devinfo -u' and 'devinfo -rv' from a broken
kernel?



Attached.


Can you also try setting 'debug.acpi.disable=sysres' in the loader?



Didn't help.



That's probably due to a typo, the corret loader tunable is
debug.acpi.disabled=sysres (note the 'd').



This helps, thanks!  Please explain what this means.


Well, it's working around a bug in your BIOS, but in this case FreeBSD should
have coped fine and it didn't.  Please try using this patch without that
tunable and get a verbose dmesg please:


Unfortunately didn't work.


Ah, it did work a bit, but it uncovered a larger bug.  I didn't make the
PCI-PCI bridge driver recursively grow windows.  Try this:



Still no luck.


--
Andrey Zonov
MP Configuration Table version 1.4 found at 0x800fcb70
Table 'FACP' at 0xdffb0290
Table 'APIC' at 0xdffb0390
APIC: Found table at 0xdffb0390
APIC: Using the MADT enumerator.
MADT: Found CPU APIC ID 0 ACPI ID 1: enabled
SMP: Added CPU 0 (AP)
MADT: Found CPU APIC ID 4 ACPI ID 2: enabled
SMP: Added CPU 4 (AP)
MADT: Found CPU APIC ID 1 ACPI ID 3: enabled
SMP: Added CPU 1 (AP)
MADT: Found CPU APIC ID 5 ACPI ID 4: enabled
SMP: Added CPU 5 (AP)
MADT: Found CPU APIC ID 2 ACPI ID 5: enabled
SMP: Added CPU 2 (AP)
MADT: Found CPU APIC ID 6 ACPI ID 6: enabled
SMP: Added CPU 6 (AP)
MADT: Found CPU APIC ID 3 ACPI ID 7: enabled
SMP: Added CPU 3 (AP)
MADT: Found CPU APIC ID 7 ACPI ID 8: enabled
SMP: Added CPU 7 (AP)
Copyright (c) 1992-2012 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
The Regents of the University of California. All rights reserved.
FreeBSD is a registered trademark of The FreeBSD Foundation.
FreeBSD 9.0-STABLE #1 r+fffa9c7-dirty: Tue Jun 12 00:44:04 MSK 2012
r...@dst-dev.yandex.ru:/usr/obj/usr/src/sys/stable9-amd64-dtrace amd64
Preloaded elf kernel "/boot/kernel.test/kernel" at 0x80f1b000.
Calibrating TSC clock ... TSC clock: 2826313691 Hz
CPU: Intel(R) Xeon(R) CPU   E5440  @ 2.83GHz (2826.31-MHz K8-class CPU)
  Origin = "GenuineIntel"  Id = 0x1067a  Family = 6  Model = 17  Stepping = 10
  
Features=0xbfebfbff
  
Features2=0xc0ce3bd
  AMD Features=0x20100800
  AMD Features2=0x1
  TSC: P-state invariant, performance statistics
real memory  = 34359738368 (32768 MB)
Physical memory chunk(s):
0x0001 - 0x0009bfff, 573440 bytes (140 pages)
0x0010 - 0x001f, 1048576 bytes (256 pages)
0x00f67000 - 0xdff9, 3741552640 bytes (913465 pages)
0xdffae000 - 0xdffa, 8192 bytes (2 pages)
0x0001 - 0x0007e2ea7fff, 29576822784 bytes (7220904 pages)
avail memory = 33113874432 (31579 MB)
Event timer "LAPIC" quality 400
ACPI APIC Table: <090808 APIC1308>
INTR: Adding local APIC 1 as a target
INTR: Adding local APIC 2 as a target
INTR: Adding local APIC 3 as a target
INTR: Adding local APIC 4 as a target
INTR: Adding local APIC 5 as a target
INTR: Adding local APIC 6 as a target
INTR: Adding local APIC 7 as a target
FreeBSD/SMP: Multiprocessor System Detected: 8 CPUs
FreeBSD/SMP: 2 package(s) x 4 core(s)
 cpu0 (BSP): APIC ID:  0
 cpu1 (AP): APIC ID:  1
 cpu2 (AP): APIC ID:  2
 cpu3 (AP): APIC ID:  3
 cpu4 (AP): APIC ID:  4
 cpu5 (AP): APIC ID:  5
 cpu6 (AP): APIC ID:  6
 cpu7 (AP): APIC ID:  7
APIC: CPU 0 has ACPI ID 1
APIC: CPU 1 has ACPI ID 3
APIC: CPU 2 ha

Re: mpt: Unable to memory map registers

2012-06-11 Thread John Baldwin

On Monday, June 11, 2012 11:25:38 am Andrey Zonov wrote:
> On 6/11/12 6:19 PM, John Baldwin wrote:
> > On Saturday, June 09, 2012 3:06:19 pm Andrey Zonov wrote:
> >> On 6/9/12 9:35 PM, Marius Strobl wrote:
> >>> On Sat, Jun 09, 2012 at 12:58:05PM +0400, Andrey Zonov wrote:
>  On 6/8/12 10:27 PM, John Baldwin wrote:
> > On Friday, June 08, 2012 11:48:50 am Andrey Zonov wrote:
> >> On Fri, Jun 8, 2012 at 7:19 PM, John Baldwin
> >> wrote:
> >>> On Friday, June 08, 2012 3:14:19 am Andrey Zonov wrote:
>  On 6/7/12 10:02 PM, Andrey Zonov wrote:
> > Hi,
> >
> > I just upgraded a few machines from 8.2-STABLE (r221983) to 9.0-
> > STABLE
> > (r234600) and now they can't find any disk because SAS controller
> > cannot
> > initialize with the following diagnostic:
> >
> > mpt0:port 0xd000-0xd0ff irq 26 at
> > device
> > 3.0 on pci6
> > mpt0: 0x4000 bytes of rid 0x14 res 3 failed (0, 0x).
> > mpt0: Unable to memory map registers.
> > mpt0: Giving Up.
> >
> > pciconf -lv:
> > mpt0@pci0:6:3:0: class=0x01 card=0x81dd1043 chip=0x00541000
> > rev=0x02
> > hdr=0x00
> > vendor = 'LSI Logic / Symbios Logic'
> > device = 'SAS1068 PCI-X Fusion-MPT SAS'
> > class = mass storage
> > subclass = SCSI
> >
> > I tried to boot to latest HEAD and found the same problem. I also
> > tried
> > to build kernel with mpt driver from my 8.2. Controller didn't
> > initialize with the same diagnostic. So it looks like the problem is
> > not
> > in mpt driver.
> >
> > Any help would be appreciated.
> >
> 
>  +jhb@
> 
>  Hi John,
> 
>  Could you please help me with the problem above?  It looks like the
>  problem is in PCI code and you changed things there.
> >>>
> >>> Can you get a verbose dmesg?
> >>>
> >>
> >> Yes, it's in attach.
> >
> > Can you get the output of 'devinfo -u' and 'devinfo -rv' from a broken
> > kernel?
> >
> 
>  Attached.
> 
> > Can you also try setting 'debug.acpi.disable=sysres' in the loader?
> >
> 
>  Didn't help.
> 
> >>>
> >>> That's probably due to a typo, the corret loader tunable is
> >>> debug.acpi.disabled=sysres (note the 'd').
> >>>
> >>
> >> This helps, thanks!  Please explain what this means.
> >
> > Well, it's working around a bug in your BIOS, but in this case FreeBSD 
> > should
> > have coped fine and it didn't.  Please try using this patch without that
> > tunable and get a verbose dmesg please:
> 
> Unfortunately didn't work.

Ah, it did work a bit, but it uncovered a larger bug.  I didn't make the
PCI-PCI bridge driver recursively grow windows.  Try this:

Index: sys/dev/pci/pci_pci.c
===
--- pci_pci.c   (revision 236888)
+++ pci_pci.c   (working copy)
@@ -113,23 +113,27 @@ DRIVER_MODULE(pcib, pci, pcib_driver, pcib_devclas
 
 /*
  * Is a resource from a child device sub-allocated from one of our
- * resource managers?
+ * resource managers?  If so, return the associated window.
  */
-static int
+static struct pcib_window *
 pcib_is_resource_managed(struct pcib_softc *sc, int type, struct resource *r)
 {
 
switch (type) {
case SYS_RES_IOPORT:
-   return (rman_is_region_manager(r, &sc->io.rman));
+   if (rman_is_region_manager(r, &sc->io.rman))
+   return (&sc->io);
+   break;
case SYS_RES_MEMORY:
/* Prefetchable resources may live in either memory rman. */
if (rman_get_flags(r) & RF_PREFETCHABLE &&
rman_is_region_manager(r, &sc->pmem.rman))
-   return (1);
-   return (rman_is_region_manager(r, &sc->mem.rman));
+   return (&sc->pmem);
+   if (rman_is_region_manager(r, &sc->mem.rman))
+   return (&sc->mem);
+   break;
}
-   return (0);
+   return (NULL);
 }
 
 static int
@@ -871,6 +875,10 @@ pcib_grow_window(struct pcib_softc *sc, struct pci
goto updatewin;
}
 
+   /* Nothing to do if the request fits in the current window. */
+   if (start >= rman_get_start(w->res) && end <= rman_get_end(w->res))
+   return (ENOSPC);
+
/*
 * See if growing the window would help.  Compute the minimum
 * amount of address space needed on both the front and back
@@ -881,6 +889,10 @@ pcib_grow_window(struct pcib_softc *sc, struct pci
 * edge of the window, grow from the inner edge of the free
 * region.  Otherwise grow from the window boundary.
 *
+* As a special case, if the new region is an exact region
+

Re: ULE Scheduler

2012-06-11 Thread Момчил Иванов

At Sat, 09 Jun 2012 20:23:44 -0700,
Doug Barton wrote:
> 
> On 06/06/2012 18:16, Doug Barton wrote:
> > On 06/06/2012 18:01, Момчил Иванов wrote:
> >> Is there some remedy?
> > 
> > Try the 4BSD scheduler.
> 
> Did you ever try this? Did it help?

I compiled the same kernel with the 4BSD scheduler today and it seems
that the processes jump accross cores too. My "eye" measure with "top"
fells like it's more stable and probably converges faster to a stable
state after "top" jumps accross cores. But in order to talk with
numbers, I need to replace "top" with somethings that dumps the
process number and the cpu id continuously in order to get some
statistics out of it, otherwise you can just forget all the things
that I have written. Is there an easy way to do that and are you
interested?

Regards,
Momchil
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: mpt: Unable to memory map registers

2012-06-11 Thread Andrey Zonov


On 6/11/12 6:19 PM, John Baldwin wrote:

On Saturday, June 09, 2012 3:06:19 pm Andrey Zonov wrote:

On 6/9/12 9:35 PM, Marius Strobl wrote:

On Sat, Jun 09, 2012 at 12:58:05PM +0400, Andrey Zonov wrote:

On 6/8/12 10:27 PM, John Baldwin wrote:

On Friday, June 08, 2012 11:48:50 am Andrey Zonov wrote:

On Fri, Jun 8, 2012 at 7:19 PM, John Baldwinwrote:

On Friday, June 08, 2012 3:14:19 am Andrey Zonov wrote:

On 6/7/12 10:02 PM, Andrey Zonov wrote:

Hi,

I just upgraded a few machines from 8.2-STABLE (r221983) to 9.0-

STABLE

(r234600) and now they can't find any disk because SAS controller
cannot
initialize with the following diagnostic:

mpt0:port 0xd000-0xd0ff irq 26 at

device

3.0 on pci6
mpt0: 0x4000 bytes of rid 0x14 res 3 failed (0, 0x).
mpt0: Unable to memory map registers.
mpt0: Giving Up.

pciconf -lv:
mpt0@pci0:6:3:0: class=0x01 card=0x81dd1043 chip=0x00541000
rev=0x02
hdr=0x00
vendor = 'LSI Logic / Symbios Logic'
device = 'SAS1068 PCI-X Fusion-MPT SAS'
class = mass storage
subclass = SCSI

I tried to boot to latest HEAD and found the same problem. I also

tried

to build kernel with mpt driver from my 8.2. Controller didn't
initialize with the same diagnostic. So it looks like the problem is
not
in mpt driver.

Any help would be appreciated.



+jhb@

Hi John,

Could you please help me with the problem above?  It looks like the
problem is in PCI code and you changed things there.


Can you get a verbose dmesg?



Yes, it's in attach.


Can you get the output of 'devinfo -u' and 'devinfo -rv' from a broken
kernel?



Attached.


Can you also try setting 'debug.acpi.disable=sysres' in the loader?



Didn't help.



That's probably due to a typo, the corret loader tunable is
debug.acpi.disabled=sysres (note the 'd').



This helps, thanks!  Please explain what this means.


Well, it's working around a bug in your BIOS, but in this case FreeBSD should
have coped fine and it didn't.  Please try using this patch without that
tunable and get a verbose dmesg please:

Index: sys/dev/pci/pci_pci.c
===
--- pci_pci.c   (revision 236888)
+++ pci_pci.c   (working copy)
@@ -893,9 +893,9 @@ pcib_grow_window(struct pcib_softc *sc, struct pci
if (start<  rman_get_start(w->res)) {
if (rman_first_free_region(&w->rman,&start_free,&end_free) !=
0 || start_free != rman_get_start(w->res))
-   end_free = rman_get_start(w->res) - 1;
+   end_free = rman_get_start(w->res);
if (end_free>  end)
-   end_free = end;
+   end_free = end + 1;

/* Move end_free down until it is properly aligned. */
end_free&= ~(align - 1);



Unfortunately didn't work.

--
Andrey Zonov
MP Configuration Table version 1.4 found at 0x800fcb70
Table 'FACP' at 0xdffb0290
Table 'APIC' at 0xdffb0390
APIC: Found table at 0xdffb0390
APIC: Using the MADT enumerator.
MADT: Found CPU APIC ID 0 ACPI ID 1: enabled
SMP: Added CPU 0 (AP)
MADT: Found CPU APIC ID 4 ACPI ID 2: enabled
SMP: Added CPU 4 (AP)
MADT: Found CPU APIC ID 1 ACPI ID 3: enabled
SMP: Added CPU 1 (AP)
MADT: Found CPU APIC ID 5 ACPI ID 4: enabled
SMP: Added CPU 5 (AP)
MADT: Found CPU APIC ID 2 ACPI ID 5: enabled
SMP: Added CPU 2 (AP)
MADT: Found CPU APIC ID 6 ACPI ID 6: enabled
SMP: Added CPU 6 (AP)
MADT: Found CPU APIC ID 3 ACPI ID 7: enabled
SMP: Added CPU 3 (AP)
MADT: Found CPU APIC ID 7 ACPI ID 8: enabled
SMP: Added CPU 7 (AP)
Copyright (c) 1992-2012 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
The Regents of the University of California. All rights reserved.
FreeBSD is a registered trademark of The FreeBSD Foundation.
FreeBSD 9.0-STABLE #0 r+fffa9c7-dirty: Mon Jun 11 18:51:03 MSK 2012
r...@dst-dev.yandex.ru:/usr/obj/usr/src/sys/stable9-amd64-dtrace amd64
Preloaded elf kernel "/boot/kernel.test/kernel" at 0x80f1b000.
Calibrating TSC clock ... TSC clock: 2826308242 Hz
CPU: Intel(R) Xeon(R) CPU   E5440  @ 2.83GHz (2826.31-MHz K8-class CPU)
  Origin = "GenuineIntel"  Id = 0x1067a  Family = 6  Model = 17  Stepping = 10
  
Features=0xbfebfbff
  
Features2=0xc0ce3bd
  AMD Features=0x20100800
  AMD Features2=0x1
  TSC: P-state invariant, performance statistics
real memory  = 34359738368 (32768 MB)
Physical memory chunk(s):
0x0001 - 0x0009bfff, 573440 bytes (140 pages)
0x0010 - 0x001f, 1048576 bytes (256 pages)
0x00f67000 - 0xdff9, 3741552640 bytes (913465 pages)
0xdffae000 - 0xdffa, 8192 bytes (2 pages)
0x0001 - 0x0007e2ea7fff, 29576822784 bytes (7220904 pages)
avail memory = 33113874432 (31579 MB)
Event timer "LAPIC" quality 400
ACPI APIC Table: <090808 APIC1308>
INTR: Adding local APIC 1 as a target
INTR: Adding local APIC 2 as a target
INTR: Adding loca

Re: mpt: Unable to memory map registers

2012-06-11 Thread John Baldwin

On Saturday, June 09, 2012 3:06:19 pm Andrey Zonov wrote:
> On 6/9/12 9:35 PM, Marius Strobl wrote:
> > On Sat, Jun 09, 2012 at 12:58:05PM +0400, Andrey Zonov wrote:
> >> On 6/8/12 10:27 PM, John Baldwin wrote:
> >>> On Friday, June 08, 2012 11:48:50 am Andrey Zonov wrote:
>  On Fri, Jun 8, 2012 at 7:19 PM, John Baldwin   wrote:
> > On Friday, June 08, 2012 3:14:19 am Andrey Zonov wrote:
> >> On 6/7/12 10:02 PM, Andrey Zonov wrote:
> >>> Hi,
> >>>
> >>> I just upgraded a few machines from 8.2-STABLE (r221983) to 9.0-
STABLE
> >>> (r234600) and now they can't find any disk because SAS controller
> >>> cannot
> >>> initialize with the following diagnostic:
> >>>
> >>> mpt0:   port 0xd000-0xd0ff irq 26 at 
device
> >>> 3.0 on pci6
> >>> mpt0: 0x4000 bytes of rid 0x14 res 3 failed (0, 0x).
> >>> mpt0: Unable to memory map registers.
> >>> mpt0: Giving Up.
> >>>
> >>> pciconf -lv:
> >>> mpt0@pci0:6:3:0: class=0x01 card=0x81dd1043 chip=0x00541000
> >>> rev=0x02
> >>> hdr=0x00
> >>> vendor = 'LSI Logic / Symbios Logic'
> >>> device = 'SAS1068 PCI-X Fusion-MPT SAS'
> >>> class = mass storage
> >>> subclass = SCSI
> >>>
> >>> I tried to boot to latest HEAD and found the same problem. I also 
tried
> >>> to build kernel with mpt driver from my 8.2. Controller didn't
> >>> initialize with the same diagnostic. So it looks like the problem is
> >>> not
> >>> in mpt driver.
> >>>
> >>> Any help would be appreciated.
> >>>
> >>
> >> +jhb@
> >>
> >> Hi John,
> >>
> >> Could you please help me with the problem above?  It looks like the
> >> problem is in PCI code and you changed things there.
> >
> > Can you get a verbose dmesg?
> >
> 
>  Yes, it's in attach.
> >>>
> >>> Can you get the output of 'devinfo -u' and 'devinfo -rv' from a broken
> >>> kernel?
> >>>
> >>
> >> Attached.
> >>
> >>> Can you also try setting 'debug.acpi.disable=sysres' in the loader?
> >>>
> >>
> >> Didn't help.
> >>
> >
> > That's probably due to a typo, the corret loader tunable is
> > debug.acpi.disabled=sysres (note the 'd').
> >
> 
> This helps, thanks!  Please explain what this means.

Well, it's working around a bug in your BIOS, but in this case FreeBSD should 
have coped fine and it didn't.  Please try using this patch without that 
tunable and get a verbose dmesg please:

Index: sys/dev/pci/pci_pci.c
===
--- pci_pci.c   (revision 236888)
+++ pci_pci.c   (working copy)
@@ -893,9 +893,9 @@ pcib_grow_window(struct pcib_softc *sc, struct pci
if (start < rman_get_start(w->res)) {
if (rman_first_free_region(&w->rman, &start_free, &end_free) !=
0 || start_free != rman_get_start(w->res))
-   end_free = rman_get_start(w->res) - 1;
+   end_free = rman_get_start(w->res);
if (end_free > end)
-   end_free = end;
+   end_free = end + 1;
 
/* Move end_free down until it is properly aligned. */
end_free &= ~(align - 1);

-- 
John Baldwin
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: su problem

2012-06-11 Thread Sami Halabi

Hi,
I opened 2 terminals with user sody.
in first i hit "su -", and supplied password, it was stcuked.
in the other I did:

%ps xau | grep su
sody  39830  0.0  0.0  9124  1500   0  S+4:51PM   0:00.00 grep su
root  39812  0.0  0.0 21732  2088   1  I 4:49PM   0:00.00 su -
root  39813  0.0  0.0 21732  2108   1  I+4:49PM   0:00.00 su -
%procstat -kk 39812
  PIDTID COMM TDNAME   KSTACK
%procstat -kk 39813
  PIDTID COMM TDNAME   KSTACK
%


Sami

On Mon, Jun 11, 2012 at 11:14 AM, Ronald Klop
wrote:

> On Sat, 09 Jun 2012 18:42:27 +0200, Eugene Grosbein 
> wrote:
>
>  09.06.2012 19:47, Sami Halabi пишет:
>>
>>> %su -
>>> Password:
>>> load: 0.00  cmd: su 30588 [ttydcd] 0.91r 0.00u 0.00s 0% 2092k
>>>
>>
>> Perpaps, your system had no keyboard attached at boot time;
>> or for some other reason it booted with /dev/console being serial console
>> instead of vidconsole. su locks trying to access serial console
>> that is /dev/ttyd0 by default and has Carrier Detect flag enabled.
>> Hence, it waits for CD on the first serial port (miserably and
>> hopelessly).
>>
>> You can check if it's true with "sysctl kern.console" command.
>> You could ask someone to boot the system with keyboard attached -
>> no need to type anything, though. The system should detect it
>> and assingn /dev/ttyv0 as /dev/console instead of /dev/ttyd0.
>> And "su" won't lock.
>>
>> Eugene Grosbein
>>
>
>
> Can you see what su is doing with procstat -kk ?
>
> __**_
> freebsd-stable@freebsd.org mailing list
> http://lists.freebsd.org/**mailman/listinfo/freebsd-**stable
> To unsubscribe, send any mail to 
> "freebsd-stable-unsubscribe@**freebsd.org
> "
>



-- 
Sami Halabi
Information Systems Engineer
NMS Projects Expert
FreeBSD SysAdmin Expert
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: world not build

2012-06-11 Thread Alexander Panyushkin


11.06.2012 16:06, Dimitry Andric написал:

On 2012-06-11 13:22, Alexander Panyushkin wrote:
...

make.conf

CPP=clang-cpp
CC=clang
CXX=clang++


the same error

There's still something in your configuration or setup that prevents
mkdep from using clang for its preprocessing.  How are you running
buildworld, exactly?  Any other non-standard configuration?

I used the standard root environment.

root@admin:/root # env
TERM=xterm
FTP_PASSIVE_MODE=YES
BLOCKSIZE=K
MAIL=/var/mail/root
PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/games:/usr/local/sbin:/usr/local/bin:/root/bin
SHELL=/bin/csh
HOME=/root
USER=root
HOSTTYPE=FreeBSD
VENDOR=amd
OSTYPE=FreeBSD
MACHTYPE=x86_64
SHLVL=1
PWD=/root
LOGNAME=root
GROUP=wheel
HOST=admin.local
EDITOR=vi
PAGER=less


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

Re: world not build

2012-06-11 Thread Dimitry Andric

On 2012-06-11 13:22, Alexander Panyushkin wrote:
...
> make.conf
> 
> CPP=clang-cpp
> CC=clang
> CXX=clang++
> 
> 
> the same error

There's still something in your configuration or setup that prevents
mkdep from using clang for its preprocessing.  How are you running
buildworld, exactly?  Any other non-standard configuration?
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: world not build

2012-06-11 Thread Alexander Panyushkin


11.06.2012 12:36, Dimitry Andric написал:

On 2012-06-11 11:31, Alexander Panyushkin wrote:

11.06.2012 12:16, Dimitry Andric написал:

On 2012-06-11 10:37, Alexander Panyushkin wrote:

...

Something in your make.conf is not working properly, causing mkdep to
run with gcc instead of clang.  I suggest removing the .if statements,
and simply using:

CC=clang
CXX=clang++
CPP=clang-cpp

I removed make.conf, but the problem remains

You cannot build libc++ with g++, you must either use clang, or set
WITHOUT_LIBCPLUSPLUS.

Which reminds me that we should really put a seatbelt in Makefile.inc1
against this... :)


make.conf

CPP=clang-cpp
CC=clang
CXX=clang++


the same error

[...cut...]/usr/src/lib/libc++/../../contrib/libc++/include/type_traits:731:2: 
error: #error is_base_of not implemented.
In file included from 
/usr/src/lib/libc++/../../contrib/libc++/include/system_error:222,
 from 
/usr/src/lib/libc++/../../contrib/libc++/src/system_error.cpp:10:
/usr/src/lib/libc++/../../contrib/libc++/include/type_traits:731:2: 
error: #error is_base_of not implemented.
In file included from 
/usr/src/lib/libc++/../../contrib/libc++/include/__functional_base:15,
 from 
/usr/src/lib/libc++/../../contrib/libc++/include/thread:90,
 from 
/usr/src/lib/libc++/../../contrib/libc++/src/thread.cpp:10:
/usr/src/lib/libc++/../../contrib/libc++/include/type_traits:731:2: 
error: #error is_base_of not implemented.
In file included from 
/usr/src/lib/libc++/../../contrib/libc++/include/exception:81,
 from 
/usr/src/lib/libc++/../../contrib/libc++/include/typeinfo:61,
 from 
/usr/src/lib/libc++/../../contrib/libc++/src/typeinfo.cpp:14:
/usr/src/lib/libc++/../../contrib/libc++/include/type_traits:731:2: 
error: #error is_base_of not implemented.
In file included from 
/usr/src/lib/libc++/../../contrib/libc++/include/__tuple:16,
 from 
/usr/src/lib/libc++/../../contrib/libc++/include/utility:125,
 from 
/usr/src/lib/libc++/../../contrib/libc++/src/utility.cpp:11:
/usr/src/lib/libc++/../../contrib/libc++/include/type_traits:731:2: 
error: #error is_base_of not implemented.
In file included from 
/usr/src/lib/libc++/../../contrib/libc++/include/cmath:302,
 from 
/usr/src/lib/libc++/../../contrib/libc++/include/valarray:344,
 from 
/usr/src/lib/libc++/../../contrib/libc++/src/valarray.cpp:10:
/usr/src/lib/libc++/../../contrib/libc++/include/type_traits:731:2: 
error: #error is_base_of not implemented.

mkdep: compile failed
*** Error code 1

Stop in /usr/src/lib/libc++.
*** Error code 1

Stop in /usr/src/lib.
*** Error code 1

Stop in /usr/src.
*** Error code 1

Stop in /usr/src.
*** Error code 1

Stop in /usr/src.
*** Error code 1

Stop in /usr/src.





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

Re: world not build

2012-06-11 Thread Dimitry Andric

On 2012-06-11 11:31, Alexander Panyushkin wrote:
> 11.06.2012 12:16, Dimitry Andric написал:
>> On 2012-06-11 10:37, Alexander Panyushkin wrote:
...
>> Something in your make.conf is not working properly, causing mkdep to
>> run with gcc instead of clang.  I suggest removing the .if statements,
>> and simply using:
>>
>> CC=clang
>> CXX=clang++
>> CPP=clang-cpp
> 
> I removed make.conf, but the problem remains

You cannot build libc++ with g++, you must either use clang, or set
WITHOUT_LIBCPLUSPLUS.

Which reminds me that we should really put a seatbelt in Makefile.inc1
against this... :)

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

Re: world not build

2012-06-11 Thread Alexander Panyushkin


11.06.2012 12:16, Dimitry Andric написал:

On 2012-06-11 10:37, Alexander Panyushkin wrote:
...

make.conf
=
CPUTYPE?=nocona
KERNCONF=Kernel
MAKE_JOBS_NUMBER=4

.if ${.CURDIR:M/usr/src} || ${.CURDIR:M/usr/src/*} ||
${.CURDIR:M/usr/obj} || ${.CURDIR:M/usr/obj/*} || ${.CURDIR:M/sys} ||
${.CURDIR:M/sys/*}
CFLAGS+= -D_FORTIFY_SOURCE=2
.if !defined(CPP) || ${CPP} == "cpp"
CPP=clang-cpp
.endif
.endif

.if !defined(CC) || ${CC} == "cc"
CC=clang
.endif
.if !defined(CXX) || ${CXX} == "c++"
CXX=clang++
.endif

...

===>  lib/libc++ (depend)
rm -f .depend
mkdep -f .depend -a -D_FORTIFY_SOURCE=2
-I/usr/src/lib/libc++/../../contrib/libc++/include
-I/usr/src/lib/libc++/../../contrib/libcxxrt -DLIBCXXRT

Something in your make.conf is not working properly, causing mkdep to
run with gcc instead of clang.  I suggest removing the .if statements,
and simply using:

CC=clang
CXX=clang++
CPP=clang-cpp


I removed make.conf, but the problem remains

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

Re: world not build

2012-06-11 Thread Dimitry Andric

On 2012-06-11 10:37, Alexander Panyushkin wrote:
...
> make.conf
> =
> CPUTYPE?=nocona
> KERNCONF=Kernel
> MAKE_JOBS_NUMBER=4
> 
> .if ${.CURDIR:M/usr/src} || ${.CURDIR:M/usr/src/*} || 
> ${.CURDIR:M/usr/obj} || ${.CURDIR:M/usr/obj/*} || ${.CURDIR:M/sys} || 
> ${.CURDIR:M/sys/*}
> CFLAGS+= -D_FORTIFY_SOURCE=2
> .if !defined(CPP) || ${CPP} == "cpp"
> CPP=clang-cpp
> .endif
> .endif
> 
> .if !defined(CC) || ${CC} == "cc"
> CC=clang
> .endif
> .if !defined(CXX) || ${CXX} == "c++"
> CXX=clang++
> .endif
...
> ===> lib/libc++ (depend)
> rm -f .depend
> mkdep -f .depend -a -D_FORTIFY_SOURCE=2 
> -I/usr/src/lib/libc++/../../contrib/libc++/include 
> -I/usr/src/lib/libc++/../../contrib/libcxxrt -DLIBCXXRT 

Something in your make.conf is not working properly, causing mkdep to
run with gcc instead of clang.  I suggest removing the .if statements,
and simply using:

CC=clang
CXX=clang++
CPP=clang-cpp
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

world not build

2012-06-11 Thread Alexander Panyushkin


world not build


FreeBSD admin.local 9.0-STABLE FreeBSD 9.0-STABLE #0: Thu May 24 
12:31:01 EEST 2012 root@admin.local:/usr/obj/usr/src/sys/Kernel amd64



make.conf
=
CPUTYPE?=nocona
KERNCONF=Kernel
MAKE_JOBS_NUMBER=4

.if ${.CURDIR:M/usr/src} || ${.CURDIR:M/usr/src/*} || 
${.CURDIR:M/usr/obj} || ${.CURDIR:M/usr/obj/*} || ${.CURDIR:M/sys} || 
${.CURDIR:M/sys/*}

CFLAGS+= -D_FORTIFY_SOURCE=2
.if !defined(CPP) || ${CPP} == "cpp"
CPP=clang-cpp
.endif
.endif

.if !defined(CC) || ${CC} == "cc"
CC=clang
.endif
.if !defined(CXX) || ${CXX} == "c++"
CXX=clang++
.endif

src.conf

WITHOUT_AMD=YES
WITHOUT_ATM=YES
WITHOUT_AUDIT=YES
WITHOUT_AUTHPF=YES
WITHOUT_BLUETOOTH=YES
WITHOUT_BSNMP=YES
WITHOUT_FREEBSD_UPDATE=YES
WITHOUT_GAMES=YES
WITHOUT_IDEA=YES
WITHOUT_INET6=YES
WITHOUT_IPFILTER=YES
WITHOUT_IPFW=YES
WITHOUT_IPX=YES
WITHOUT_JAIL=YES
WITHOUT_KERBEROS=YES
WITHOUT_NCP=yes
WITHOUT_NDIS=YES
WITHOUT_NIS=YES
WITHOUT_PROFILE=YES
WITHOUT_QUOTAS=YES
WITHOUT_RCMDS=YES
WITHOUT_RCS=YES
WITH_BIND_LARGE_FILE=YES
WITH_BIND_LIBS=YES
WITH_BIND_XML=YES
WITH_CLANG=YES
WITH_CLANG_EXTRAS=YES
WITH_LIBCPLUSPLUS=YES

mkdep -f .depend -a -D_FORTIFY_SOURCE=2 -D_XOPEN_SOURCE_EXTENDED 
-DENABLE_WIDEC -I. -I/usr/obj/usr/src/lib/ncurses/panelw/../ncursesw 
-I/usr/src/lib/ncurses/panelw/../ncursesw 
-I/usr/src/lib/ncurses/panelw/../ncurses 
-I/usr/src/lib/ncurses/panelw/../../../contrib/ncurses/include 
-I/usr/src/lib/ncurses/panelw/../../../contrib/ncurses/ncurses -DNDEBUG 
-DHAVE_CONFIG_H 
-I/usr/src/lib/ncurses/panelw/../../../contrib/ncurses/panel 
/usr/src/lib/ncurses/panelw/../../../contrib/ncurses/panel/p_above.c 
/usr/src/lib/ncurses/panelw/../../../contrib/ncurses/panel/p_below.c 
/usr/src/lib/ncurses/panelw/../../../contrib/ncurses/panel/p_bottom.c 
/usr/src/lib/ncurses/panelw/../../../contrib/ncurses/panel/p_delete.c 
/usr/src/lib/ncurses/panelw/../../../contrib/ncurses/panel/p_hidden.c 
/usr/src/lib/ncurses/panelw/../../../contrib/ncurses/panel/p_hide.c 
/usr/src/lib/ncurses/panelw/../../../contrib/ncurses/panel/p_move.c 
/usr/src/lib/ncurses/panelw/../../../contrib/ncurses/panel/p_new.c 
/usr/src/lib/nc
 urses/panelw/../../../contrib/ncurses/panel/p_replace.c 
/usr/src/lib/ncurses/panelw/../../../contrib/ncurses/panel/p_show.c 
/usr/src/lib/ncurses/panelw/../../../contrib/ncurses/panel/p_top.c 
/usr/src/lib/ncurses/panelw/../../../contrib/ncurses/panel/p_update.c 
/usr/src/lib/ncurses/panelw/../../../contrib/ncurses/panel/p_user.c 
/usr/src/lib/ncurses/panelw/../../../contrib/ncurses/panel/p_win.c 
/usr/src/lib/ncurses/panelw/../../../contrib/ncurses/panel/panel.c

echo libpanelw.so.5: /usr/obj/usr/src/tmp/usr/lib/libncursesw.a >> .depend
===> lib/libnetgraph (depend)
rm -f .depend
mkdep -f .depend -a -D_FORTIFY_SOURCE=2 /usr/src/lib/libnetgraph/sock.c 
/usr/src/lib/libnetgraph/msg.c /usr/src/lib/libnetgraph/debug.c

===> lib/libradius (depend)
===> lib/librpcsvc (depend)
RPCGEN_CPP=cpp rpcgen -C -c 
/usr/src/lib/librpcsvc/../../include/rpcsvc/klm_prot.x -o klm_prot_xdr.c
RPCGEN_CPP=cpp rpcgen -C -c 
/usr/src/lib/librpcsvc/../../include/rpcsvc/mount.x -o mount_xdr.c
RPCGEN_CPP=cpp rpcgen -C -c 
/usr/src/lib/librpcsvc/../../include/rpcsvc/nfs_prot.x -o nfs_prot_xdr.c
RPCGEN_CPP=cpp rpcgen -C -c 
/usr/src/lib/librpcsvc/../../include/rpcsvc/nlm_prot.x -o nlm_prot_xdr.c
RPCGEN_CPP=cpp rpcgen -C -c 
/usr/src/lib/librpcsvc/../../include/rpcsvc/rex.x -o rex_xdr.c
RPCGEN_CPP=cpp rpcgen -C -c 
/usr/src/lib/librpcsvc/../../include/rpcsvc/rnusers.x -o rnusers_xdr.c
RPCGEN_CPP=cpp rpcgen -C -c 
/usr/src/lib/librpcsvc/../../include/rpcsvc/rquota.x -o rquota_xdr.c
RPCGEN_CPP=cpp rpcgen -C -c 
/usr/src/lib/librpcsvc/../../include/rpcsvc/rstat.x -o rstat_xdr.c
RPCGEN_CPP=cpp rpcgen -C -c 
/usr/src/lib/librpcsvc/../../include/rpcsvc/rwall.x -o rwall_xdr.c
RPCGEN_CPP=cpp rpcgen -C -c 
/usr/src/lib/librpcsvc/../../include/rpcsvc/sm_inter.x -o sm_inter_xdr.c
RPCGEN_CPP=cpp rpcgen -C -c 
/usr/src/lib/librpcsvc/../../include/rpcsvc/spray.x -o spray_xdr.c
RPCGEN_CPP=cpp rpcgen -C -c 
/usr/src/lib/librpcsvc/../../include/rpcsvc/yppasswd.x -o yppasswd_xdr.c
RPCGEN_CPP=cpp rpcgen -C -c 
/usr/src/lib/librpcsvc/../../include/rpcsvc/ypxfrd.x -o ypxfrd_xdr.c
RPCGEN_CPP=cpp rpcgen -C -c 
/usr/src/lib/librpcsvc/../../include/rpcsvc/ypupdate_prot.x -o 
ypupdate_prot_xdr.c

rm -f .depend
mkdep -f .depend -a -D_FORTIFY_SOURCE=2 -DYP 
-I/usr/obj/usr/src/tmp/usr/include/rpcsvc klm_prot_xdr.c mount_xdr.c 
nfs_prot_xdr.c nlm_prot_xdr.c rex_xdr.c rnusers_xdr.c rquota_xdr.c 
rstat_xdr.c rwall_xdr.c sm_inter_xdr.c spray_xdr.c yppasswd_xdr.c 
ypxfrd_xdr.c ypupdate_prot_xdr.c /usr/src/lib/librpcsvc/rnusers.c 
/usr/src/lib/librpcsvc/rstat.c /usr/src/lib/librpcsvc/rwall.c 
/usr/src/lib/librpcsvc/secretkey.c /usr/src/lib/librpcsvc/xcrypt.c

===> lib/libsbuf (depend)
===> lib/libtacplus (depend)
===> lib/libutil (depend)
===> lib/libcxxrt (depend)
===> lib/libc++ (depend)
rm -f .depend
mkdep -f .depend -a -D_FORTIFY_SOURCE=2 
-I/usr/src/lib/libc++/../../contrib

Re: su problem

2012-06-11 Thread Ronald Klop

On Sat, 09 Jun 2012 18:42:27 +0200, Eugene Grosbein   
wrote:



09.06.2012 19:47, Sami Halabi пишет:

%su -
Password:
load: 0.00  cmd: su 30588 [ttydcd] 0.91r 0.00u 0.00s 0% 2092k


Perpaps, your system had no keyboard attached at boot time;
or for some other reason it booted with /dev/console being serial console
instead of vidconsole. su locks trying to access serial console
that is /dev/ttyd0 by default and has Carrier Detect flag enabled.
Hence, it waits for CD on the first serial port (miserably and  
hopelessly).


You can check if it's true with "sysctl kern.console" command.
You could ask someone to boot the system with keyboard attached -
no need to type anything, though. The system should detect it
and assingn /dev/ttyv0 as /dev/console instead of /dev/ttyd0.
And "su" won't lock.

Eugene Grosbein



Can you see what su is doing with procstat -kk ?
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: if_bridge panic removing member

2012-06-11 Thread David


Hi,

Patch work for me

One thing I don't understand is why this bug only happen on amd64 ?

Regards

David

Le 10.06.2012 22:50, Andrew Thompson a écrit :

On 11 June 2012 08:48, David ROFFIAEN  wrote:

Hi list,

On FreeBSD 9-stable (csup from today) with amd64 arch (only, no poblem with
the same source on i386) kernel panic when removing member form the bridge :
to reproduce :

# ifconfig bridge0 create addm em0
# ifconfig bridge0 deletem em0

the problem is the same with all interfaces (tested with wlan vlan em)

It seems to become for a new function in net/if_bridge.c :
  bridge_linkstate, not existing previously when it worked on amd64 (one
month ago)


I introduced this issue in r234487, please try this patch.
http://people.freebsd.org/~thompsa/bridge_link.diff

regards,
Andrew
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"



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

Re: Documenting ports options (was Re: Why Are You NOT Using FreeBSD ?)

GCC-4.6-20120608 has a corrupt archive or a bad checksum

Re: Why Are You NOT Using FreeBSD ?

Re: Why Are You NOT Using FreeBSD ?

Re: Documenting ports options (was Re: Why Are You NOT Using FreeBSD ?)

Documenting ports options (was Re: Why Are You NOT Using FreeBSD ?)

Re: mpt: Unable to memory map registers

Re: mpt: Unable to memory map registers

Re: ULE Scheduler

Re: mpt: Unable to memory map registers

Re: mpt: Unable to memory map registers

Re: su problem

Re: world not build

Re: world not build

Re: world not build

Re: world not build

Re: world not build

Re: world not build

world not build

Re: su problem

Re: if_bridge panic removing member

21 matches

Site Navigation

Mail list logo

Footer information