Re: Intel 82574 issue reported on Slashdot

[Johnny Eriksson]

> In all honesty.. The blog post (and your email) are basically
> information free, they don't name names and provide no script
> or downloadable code that will allow end users to check if they
> are affected.

A link with a little bit more information:

  http://blog.krisk.org/2013/02/packets-of-death.html

> Daniel O'Connor software and network engineer

--Johnny
___
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: uath panic on insert.

[Ian FREISLICH]

Hans Petter Selasky wrote:
> On Friday 08 February 2013 22:43:17 Ian FREISLICH wrote:
> > Hans Petter Selasky wrote:
> > > Hi,
> > > 
> > > Your problem should be fixed by:
> > > http://svnweb.freebsd.org/changeset/base/246565
> > > 
> > > Please test and report back if it doesn't.
> > 
> > It doesn't panic anymore.  Thanks.  There's a new problem though:
> > 
> > uath0: 
> > on usbus1 wlan1: Ethernet address: 00:11:95:d3:4a:af
> 
> Hi,
> 
> Can you try this patch:
> http://svnweb.freebsd.org/changeset/base/246570

ugen1.5:  at usbus1
 on usbus1
Ethernet address: 00:11:95:d3:4a:af
uath_cmdsend: empty inactive queue
could not init Tx queues, error 55
uath_cmdsend: empty inactive queue
could not set channel, error 55
uath_cmdsend: empty inactive queue
could not set channel, error 55
uath_cmdsend: empty inactive queue
could not set channel, error 55
uath_cmdsend: empty inactive queue
could not set channel, error 55
uath_cmdsend: empty inactive queue
could not set channel, error 55
at uhub2, port 2, addr 5 (disconnected) <---
uath_cmdsend: empty inactive queue
uath_cmdsend: empty inactive queue
ugen1.5:  at usbus1 (disconnected)

The card still disconnects after attempting to scan unsupported
frequencies.  The sequence above happens when I 'ifconfig wlan1
up'.  Also, the uath driver reports 2.4GHz and 5GHz as supported
channels for this chip but it's a D-Link DWL-G132 which is a 2.4GHz
device.  Is this a problem for Adrian to look at?

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: uath panic on insert.

[Hans Petter Selasky]

On Saturday 09 February 2013 09:47:46 Ian FREISLICH wrote:
> Hans Petter Selasky wrote:
> > On Friday 08 February 2013 22:43:17 Ian FREISLICH wrote:
> > > Hans Petter Selasky wrote:
> > > > Hi,
> > > > 
> > > > Your problem should be fixed by:
> > > > http://svnweb.freebsd.org/changeset/base/246565
> > > > 
> > > > Please test and report back if it doesn't.
> > > 
> > > It doesn't panic anymore.  Thanks.  There's a new problem though:
> > > 
> > > uath0:  > > 5> on usbus1 wlan1: Ethernet address: 00:11:95:d3:4a:af
> > 
> > Hi,
> > 
> > Can you try this patch:
> > http://svnweb.freebsd.org/changeset/base/246570
> 
> ugen1.5:  at usbus1
>  on
> usbus1 Ethernet address: 00:11:95:d3:4a:af
> uath_cmdsend: empty inactive queue
> could not init Tx queues, error 55
> uath_cmdsend: empty inactive queue
> could not set channel, error 55
> uath_cmdsend: empty inactive queue
> could not set channel, error 55
> uath_cmdsend: empty inactive queue
> could not set channel, error 55
> uath_cmdsend: empty inactive queue
> could not set channel, error 55
> uath_cmdsend: empty inactive queue
> could not set channel, error 55
> at uhub2, port 2, addr 5 (disconnected) <---
> uath_cmdsend: empty inactive queue
> uath_cmdsend: empty inactive queue
> ugen1.5:  at usbus1 (disconnected)
> 
> The card still disconnects after attempting to scan unsupported
> frequencies.  The sequence above happens when I 'ifconfig wlan1
> up'.  Also, the uath driver reports 2.4GHz and 5GHz as supported
> channels for this chip but it's a D-Link DWL-G132 which is a 2.4GHz
> device.  Is this a problem for Adrian to look at?

Hi,

I see the same over here. I think it is not a USB problem.

--HPS
___
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: HEAD memsticks broken? [USB/CAM Problems?]

[Joel Dahl]

On 09-02-2013  8:32, Joel Dahl wrote:
> Hi,
> 
> I suspect something is broken with memsticks built from HEAD. I noticed that I
> couldn't boot the latest HEAD (amd64) memstick snapshot on two machines
> (Lenovo X220 and HP ProLiant ML350 G5). Trying snapshots from the FreeBSD.org
> FTP or allbsd.org makes no difference.

I compared output from booting RELENG_9 and HEAD:

RELENG_9:

ugen2.3:  at usbus2
umass0:  on usbus2
umass0:  SCSI over Bulk-Only; quirks = 0x0100
umass0:4:0:-1: Attached to scbus4
da0 at umass-sim0 bus 0 scbus4 target 0 lun 0
da0:  Removable Direct Access SCSI-2 device 
???
da0: 40.000MB/s transfers
da0: 1905MB (3903264 512 byte sectors: 255H 63S/T 24SC)
(da0-umass-sim0:0:0:0): PREVENT ALLOW MEDIUM REMOVAL. CDB: 1e 0 0 0 1 0
(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: No sense data present
(da0-umass-sim0:0:0:0): Retrying command (per sense data)



Root mount waiting for: usbus2
ugen2.4:  at usbus2
Trying to mount root from ufs:/dev/ufs/FreeBSD_Install [ro,noatime]...
Starting file system checks:
/dev/ufs/FreeBSD_Install: FILE SYSTEM CLEAN; SKIPPING CHECKS
/dev/ufs/FreeBSD_Install: clean, 43155 free (507 frags, 5331 blocks, 0.1% 
fragmentation)
Mounting local file systems:.

and it works.

HEAD:

ugen2.3:  at usbus2
umass0:  on usbus2
umass0:  SCSI over Bulk-Only; quirks = 0x0100
umass0:5:0:-1: Attached to scbus5
da0 at umass-sim0 bus 0 scbus5 target 0 lun 0
da0:  Removable Direct Access SCSI-0 device 
??
da0: 40.000MB/s transfers
da0: 3690MB (7557704 512 byte sectors: 255H 63S/T 470SC)
(da0-umass-sim0:0:0:0): PREVENT ALLOW MEDIUM REMOVAL. CDB: 1e 0 0 0 1 0
(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: No sense data present
(da0-umass-sim0:0:0:0): Retrying command (per sense data)



(da0-umass-sim0:0:0:0): Error 5, Retries exhausted
(da0-umass-sim0:0:0:0): got CAM status 0x8c
(da0-umass-sim0:0:0:0): fatal error, failed to attach to device
(da0-umass-sim0:0:0:0): lost device - 0 outstanding, 4 refs
(da0-umass-sim0:0:0:0): removing device entry
ugen2.4:  at usbus2
Trying to mount root from ufs:/dev/ufs/FreeBSD_Install [ro,noatime]...
mountroot: waiting for device /dev/ufs/FreeBSD_Install ...
Mounting from ufs:/dev/ufs/FreeBSD_Install failed with error 19.

BOOM

-- 
Joel
___
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: HEAD memsticks broken? [USB/CAM Problems?]

[Hans Petter Selasky]

On Saturday 09 February 2013 10:26:59 Joel Dahl wrote:
> On 09-02-2013  8:32, Joel Dahl wrote:
> > Hi,
> > 
> > I suspect something is broken with memsticks built from HEAD. I noticed
> > that I couldn't boot the latest HEAD (amd64) memstick snapshot on two
> > machines (Lenovo X220 and HP ProLiant ML350 G5). Trying snapshots from
> > the FreeBSD.org FTP or allbsd.org makes no difference.
> 
> I compared output from booting RELENG_9 and HEAD:
> 
> RELENG_9:
> 
> ugen2.3:  at usbus2
> umass0:  on
> usbus2 umass0:  SCSI over Bulk-Only; quirks = 0x0100
> umass0:4:0:-1: Attached to scbus4
> da0 at umass-sim0 bus 0 scbus4 target 0 lun 0
> da0:  Removable Direct Access SCSI-2 device
> ??? da0: 40.000MB/s transfers
> da0: 1905MB (3903264 512 byte sectors: 255H 63S/T 24SC)
> (da0-umass-sim0:0:0:0): PREVENT ALLOW MEDIUM REMOVAL. CDB: 1e 0 0 0 1 0
> (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: No sense data present
> (da0-umass-sim0:0:0:0): Retrying command (per sense data)
> 
> 
> 
> Root mount waiting for: usbus2
> ugen2.4:  at usbus2
> Trying to mount root from ufs:/dev/ufs/FreeBSD_Install [ro,noatime]...
> Starting file system checks:
> /dev/ufs/FreeBSD_Install: FILE SYSTEM CLEAN; SKIPPING CHECKS
> /dev/ufs/FreeBSD_Install: clean, 43155 free (507 frags, 5331 blocks, 0.1%
> fragmentation) Mounting local file systems:.
> 
> and it works.
> 
> HEAD:
> 
> ugen2.3:  at usbus2
> umass0:  on
> usbus2 umass0:  SCSI over Bulk-Only; quirks = 0x0100
> umass0:5:0:-1: Attached to scbus5
> da0 at umass-sim0 bus 0 scbus5 target 0 lun 0
> da0:  Removable Direct Access SCSI-0 device
> ?? da0: 40.000MB/s transfers
> da0: 3690MB (7557704 512 byte sectors: 255H 63S/T 470SC)
> (da0-umass-sim0:0:0:0): PREVENT ALLOW MEDIUM REMOVAL. CDB: 1e 0 0 0 1 0
> (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: No sense data present
> (da0-umass-sim0:0:0:0): Retrying command (per sense data)
> 
> 
> 
> (da0-umass-sim0:0:0:0): Error 5, Retries exhausted
> (da0-umass-sim0:0:0:0): got CAM status 0x8c
> (da0-umass-sim0:0:0:0): fatal error, failed to attach to device
> (da0-umass-sim0:0:0:0): lost device - 0 outstanding, 4 refs
> (da0-umass-sim0:0:0:0): removing device entry
> ugen2.4:  at usbus2
> Trying to mount root from ufs:/dev/ufs/FreeBSD_Install [ro,noatime]...
> mountroot: waiting for device /dev/ufs/FreeBSD_Install ...
> Mounting from ufs:/dev/ufs/FreeBSD_Install failed with error 19.

Hi,

You can try to set the no-synchronize cache quirk in 
sys/dev/usb/quirk/usb_quirk.c for your device. I'm not sure if it helps, but 
else I suspect it is not an USB issue.

--HPS
___
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: Intel 82574 issue reported on Slashdot

[Daniel O'Connor]

On 09/02/2013, at 20:42, Parv  wrote:
>> "Contact your motherboard manufacturer" is much more time
>> consuming than "Run sysctl... | grep foo | awk ..." to see if your
>> system is affected.
> 
> Gift^WStraight from horse's mouth ...
> 
>  http://blog.krisk.org/2013/02/packets-of-death.html

I've already read this.

>  http://www.kriskinc.com/intel-pod

I'd really rather a test which reads the EEPROM and tells me if it's a problem 
rather than hang the interface on a machine :)

In any case that isn't the point - this may be a "vendor issue" but it reflects 
poorly on Intel that they didn't take proper ownership of the issue. It would 
be far, far better for their image to say "some systems may have the fault, go 
to http:// to find a way to test for your operating system".

--
Daniel O'Connor software and network engineer
for Genesis Software - http://www.gsoft.com.au
"The nice thing about standards is that there
are so many of them to choose from."
  -- Andrew Tanenbaum
GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C






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

Summary of junk emails blocked - 1 Junk Emails Blocked

[Admin Junk Summary]

Junk Box Summary for: curr...@freebsd.org

The 1 emails listed below have been placed in your personal Junk Box
since your last Junk Box Summary and will be deleted after 30 days.
To retrieve any of these messages, visit your Junk Box at:



Login using your standard username/password combination.

Junk Box Summary
-
 n...@gmail.com  
=?windows-1251?B?W8rIxcJdIMLA0NjAwtHKwN8gwcjQxsAg1sXNzd...
-

Junk blocking by SonicWALL

___
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: Intel 82574 issue reported on Slashdot

[O. Hartmann]

Am 02/09/13 09:15, schrieb Johnny Eriksson:
>> In all honesty.. The blog post (and your email) are basically
>> information free, they don't name names and provide no script
>> or downloadable code that will allow end users to check if they
>> are affected.
> 
> A link with a little bit more information:
> 
>   http://blog.krisk.org/2013/02/packets-of-death.html
> 
>> Daniel O'Connor software and network engineer
> 
> --Johnny


We don't even have the tool tcpreplay in the ports mentioned in that BLOG.

oh



signature.asc
Description: OpenPGP digital signature

Re: geli(8) breaks after a couple hours of uptime

[Fabian Keil]

Eitan Adler  wrote:

> On 8 February 2013 07:46, Andriy Gapon  wrote:
> > on 08/02/2013 13:48 Ulrich Spörlein said the following:

> >> It looks like 128k as a limit is still too low for geli(8) to work, and
> >> I've set it to 256k now, so that I can use "sudo geli". Can you maybe
> >> revise the patch to not use 1024k as an arbitrary limit, but rather make
> >> sure you test for precisely as much memory as will be needed?

IIRC 256K didn't work for me, 512K did, so I doubled it
to have some leg room.

I'm not sure it's possible to reliably estimate the required
memory without first changing geli to mlock less generously,
something Konstantin suggested in:
http://lists.freebsd.org/pipermail/svn-src-all/2013-January/063939.html

While I agree that mlocking less generously would technically be a
better solution than increasing the limit, it would also require a lot
more work, additional audits to make sure it's done correctly and in
case of geli I don't really see a problem with mlocking 1024K for a
few seconds.

> >> Also, can we maybe revisit the new 64k default limit, as it will
> >> obviously make peoples work with geli a bit painful, this should work
> >> out of the box.
> >
> > I have some, IMO, better suggestions:
> > - use -c option with sudo

I usually execute "sudo geli" through a wrapper (zogftw) so this
makes patching geli optional for me. Thanks for mentioning it (again).

> > - tune your system for your needs
> >
> > - [major] abolish the silliness of tying resource limits to login class and 
> > apply
> > resource limits based on user and group IDs; including after su/sudo 
> > (subject to
> > local policies)

While we are dreaming, it would be nice to have more resource limits
that apply to all the processes belonging to the user combined.

It also wouldn't hurt to document why a 64K per-process limit with an
unlimited number of processes per user is considered a good default in
the first place.

> The default settings should not make another feature unusable.  At a
> minimum it should be documented in geli's man page that such tuning is
> required.

If the consensus is that 1024K are too much for geli and nobody can
be bothered to come up with a more fine grained mlocking patch,
geli could be changed to check the mlock limit and exit with a
useful error message if it's too low.

This would at least prevent the segfault.

Fabian


signature.asc
Description: PGP signature

Re: Intel 82574 issue reported on Slashdot

[Parv]

in message ,
wrote Daniel O'Connor thusly...
>
>
> On 09/02/2013, at 4:46, Jack Vogel  wrote:
>
> > recommends contacting your motherboard manufacturer if you have
> > continued concerns or questions whether your products are
> > impacted.  Here is the link:
> >
> > http://communities.intel.com/community/wired/blog/2013/02/07/intel-82574l-gigabit-ethernet-controller-statement
> >
> > Any questions or concerns may be sent to me.
>
> In all honesty.. The blog post (and your email) are basically
> information free, they don't name names and provide no script or
> downloadable code that will allow end users to check if they are
> affected.

> "Contact your motherboard manufacturer" is much more time
> consuming than "Run sysctl... | grep foo | awk ..." to see if your
> system is affected.

Gift^WStraight from horse's mouth ...

  http://blog.krisk.org/2013/02/packets-of-death.html

  http://www.kriskinc.com/intel-pod


  - parv

-- 

___
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: Physbio changes final call for tests and reviews

[Fabian Keil]

Konstantin Belousov  wrote:

> I finished the last (insignificant) missed bits in the Jeff' physbio
> work. Now I am asking for the last round of testing and review, esp. for
> the !x86 architectures. Another testing focus are the SCSI HBAs and RAID
> controllers which drivers are changed by the patchset. Please do test
> this before the patchset is committed into HEAD !

I could only test on amd64 without fancy SCSI controllers,
but it works for me.

Fabian


signature.asc
Description: PGP signature

Re: Intel 82574 issue reported on Slashdot

[Christoph Moench-Tegeder]

## O. Hartmann (ohart...@zedat.fu-berlin.de):

> We don't even have the tool tcpreplay in the ports mentioned in that BLOG.

It's in net-mgmt/tcpreplay.

Regards,
Christoph

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

Destroying ZFS snapshots "too quickly": xpt_scan_lun: can't allocate CCB, can't continue

[Fabian Keil]

Before the introduction of async_destroy I wrote a script to destroy
ZFS snapshots in parallel to speed up the process. It's available at:
http://www.fabiankeil.de/sourcecode/zfs-snapshot-destroyer/zsd.pl

A couple of years ago the only downside seemed to be that it
requires more memory and file descriptors (due to multiple zfs
processes running at the same time) and that errors are ignored
(implementation detail of the script).

Recently I noticed that destroying several hundred (500)
snapshots this way risks rendering the system unresponsive.
I rarely do that, so it might not actually be a regression.

When using X the screen freezes and keyboard input is ignored
so it's hard to tell what's going on.

When running the script on the console alt+Fx are often still
accepted to switch consoles, but other keyboard input like
entering commands or trying to login has no visible effect.

A running top is killed and the system frequently logs:
"xpt_scan_lun: can't allocate CCB, can't continue".

Plugging in USB devices still result in the expected messages,
but other than this the system seems to be unresponsive and
doesn't recover (I only waited a couple of minutes, though).

A "CCB" seems to be rather small:
http://fxr.watson.org/fxr/source/cam/cam_xpt.c#L4386
therefore I suspect that ZFS got greedy and didn't play nice
with the rest of the system. I have no proof that ZFS isn't
merely triggering a problem in another subsystem, though.

So far I haven't been able to reproduce the problem with snapshots
intentionally created for testing, but I also used a somewhat
simplistic approach to populate the snapshots.

Is this considered a bug or is quickly destroying snapshots just
something for the "don't do this" or "not without proper tuning"
departments?

I would also be interested to know if there's a way to somehow
roughly figure out from userland how many snapshots can be safely
destroyed in a row. Example: Look at "some" system state, destroy
a safe amount of snapshots, look at "some" system state again and
interpolate.

Before top gets killed it usually shows that zfskern takes
more than 50% WCPU, but this can also happen when the system
doesn't become unresponsive and thus probably isn't a good
metric (the delay also doesn't help of course).

Fabian


signature.asc
Description: PGP signature

Re: geli(8) breaks after a couple hours of uptime

[Andrey Zonov]

On 2/9/13 5:07 PM, Fabian Keil wrote:
> 
> This would at least prevent the segfault.
> 

I see two possibilities to get segfault:
  - no checking for result from memory allocation functions
  - too big stack

I have no found any broken memory allocation checking, but I found two
big objects on the stack.  One is buf[MAXPHYS] in eli_genkey_files() and
another is passbuf[MAXPHYS] in eli_genkey_passphrase().  If we change
these two to malloc(), then we can handle error from malloc(), print
some useful message and prevent segfault.

-- 
Andrey Zonov



signature.asc
Description: OpenPGP digital signature

Re: Intel 82574 issue reported on Slashdot

[CeDeROM]

On Sat, Feb 9, 2013 at 3:44 PM, Christoph Moench-Tegeder
 wrote:
> ## O. Hartmann (ohart...@zedat.fu-berlin.de):
>> We don't even have the tool tcpreplay in the ports mentioned in that BLOG.
> It's in net-mgmt/tcpreplay.

And I managed to build mentioned Ostinato packet crafting utility with
no problem on my FreeBSD 9.1-RELEASE AMD64. If they provide package
and release (which I already asked from the authors) I will make a
port for this tool as well :-)

Best regards :-)
Tomek

-- 
CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
___
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: geli(8) breaks after a couple hours of uptime

[Andriy Gapon]

on 09/02/2013 15:07 Fabian Keil said the following:
> It also wouldn't hurt to document why a 64K per-process limit with an
> unlimited number of processes per user is considered a good default in
> the first place.

I don't think that maxproc=unlimited is a good default regardless of
memorylocked.  OTOH, we have kern.maxprocperuid.

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

Re: geli(8) breaks after a couple hours of uptime

[Andriy Gapon]

on 09/02/2013 17:04 Andrey Zonov said the following:
> On 2/9/13 5:07 PM, Fabian Keil wrote:
>>
>> This would at least prevent the segfault.
>>
> 
> I see two possibilities to get segfault:
>   - no checking for result from memory allocation functions
>   - too big stack
> 
> I have no found any broken memory allocation checking, but I found two
> big objects on the stack.  One is buf[MAXPHYS] in eli_genkey_files() and
> another is passbuf[MAXPHYS] in eli_genkey_passphrase().  If we change
> these two to malloc(), then we can handle error from malloc(), print
> some useful message and prevent segfault.

I'd rather do what Kostik suggested and Fabian mentioned: instead of
mlockall(MCL_FUTURE) the code should mlock only the (explicitly designated)
buffers that can contain sensitive data.

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

Re: [patch] Userland DTrace

[Sevan / Venture37]

On 08/02/2013 20:04, Matt Burke wrote:

I've been spending some time trying to get the fasttrap provider to work
on FreeBSD without panicing. I believe I have succeeded, at least to the
point where it's no longer panicing.

There were two panic causes. The first was
http://www.freebsd.org/cgi/query-pr.cgi?pr=165541 - the FreeBSD port of
fasttrap.c caused ftp_rcount to be left >0. To fix this I've got rid of
the early return and reverted to the opensolaris way.

A second panic then showed up intermittently when fasttrap_pid_cleanup_cb
was run while something in userland had locks. Using sx_try_xlock calls
has stopped the panics and shouldn't affect operation AFAICT.

This is against r246454.


Although this has fixed the panics for me, I'm finding a lot of stuff just
isn't actually working, with dtrace and the traced process just chewing
CPU. Truss on the dtrace shows a heck of a lot of ptrace() calls and I
have no idea what the target is doing... CPU time is split 2:1
dtrace:target


Also noteworthy is the LOR on the first time you try to use the fasttrap
provider: http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/165479

The lock order there seems right, so I'm guessing "something else" must
have done it wrong first? How can I find out what the "something else"
is?


Hi Matt,
It might be worth posting the question to the dtrace list if your 
question is unanswered.

http://dtrace.org/blogs/mailing-list/

Regards,

Sevan
___
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: HEAD memsticks broken? [USB/CAM Problems?]

[Alexander Motin]

On 09.02.2013 12:15, Hans Petter Selasky wrote:
> On Saturday 09 February 2013 10:26:59 Joel Dahl wrote:
>> On 09-02-2013  8:32, Joel Dahl wrote:
>>> Hi,
>>>
>>> I suspect something is broken with memsticks built from HEAD. I noticed
>>> that I couldn't boot the latest HEAD (amd64) memstick snapshot on two
>>> machines (Lenovo X220 and HP ProLiant ML350 G5). Trying snapshots from
>>> the FreeBSD.org FTP or allbsd.org makes no difference.
>>
>> I compared output from booting RELENG_9 and HEAD:
>>
>> RELENG_9:
>>
>> ugen2.3:  at usbus2
>> umass0:  on
>> usbus2 umass0:  SCSI over Bulk-Only; quirks = 0x0100
>> umass0:4:0:-1: Attached to scbus4
>> da0 at umass-sim0 bus 0 scbus4 target 0 lun 0
>> da0:  Removable Direct Access SCSI-2 device
>> ??? da0: 40.000MB/s transfers
>> da0: 1905MB (3903264 512 byte sectors: 255H 63S/T 24SC)
>> (da0-umass-sim0:0:0:0): PREVENT ALLOW MEDIUM REMOVAL. CDB: 1e 0 0 0 1 0
>> (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: No sense data present
>> (da0-umass-sim0:0:0:0): Retrying command (per sense data)
>> 
>> 
>> 
>> Root mount waiting for: usbus2
>> ugen2.4:  at usbus2
>> Trying to mount root from ufs:/dev/ufs/FreeBSD_Install [ro,noatime]...
>> Starting file system checks:
>> /dev/ufs/FreeBSD_Install: FILE SYSTEM CLEAN; SKIPPING CHECKS
>> /dev/ufs/FreeBSD_Install: clean, 43155 free (507 frags, 5331 blocks, 0.1%
>> fragmentation) Mounting local file systems:.
>>
>> and it works.
>>
>> HEAD:
>>
>> ugen2.3:  at usbus2
>> umass0:  on
>> usbus2 umass0:  SCSI over Bulk-Only; quirks = 0x0100
>> umass0:5:0:-1: Attached to scbus5
>> da0 at umass-sim0 bus 0 scbus5 target 0 lun 0
>> da0:  Removable Direct Access SCSI-0 device
>> ?? da0: 40.000MB/s transfers
>> da0: 3690MB (7557704 512 byte sectors: 255H 63S/T 470SC)
>> (da0-umass-sim0:0:0:0): PREVENT ALLOW MEDIUM REMOVAL. CDB: 1e 0 0 0 1 0
>> (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: No sense data present
>> (da0-umass-sim0:0:0:0): Retrying command (per sense data)
>> 
>> 
>> 
>> (da0-umass-sim0:0:0:0): Error 5, Retries exhausted
>> (da0-umass-sim0:0:0:0): got CAM status 0x8c
>> (da0-umass-sim0:0:0:0): fatal error, failed to attach to device
>> (da0-umass-sim0:0:0:0): lost device - 0 outstanding, 4 refs
>> (da0-umass-sim0:0:0:0): removing device entry
>> ugen2.4:  at usbus2
>> Trying to mount root from ufs:/dev/ufs/FreeBSD_Install [ro,noatime]...
>> mountroot: waiting for device /dev/ufs/FreeBSD_Install ...
>> Mounting from ufs:/dev/ufs/FreeBSD_Install failed with error 19.
> 
> Hi,
> 
> You can try to set the no-synchronize cache quirk in 
> sys/dev/usb/quirk/usb_quirk.c for your device. I'm not sure if it helps, but 
> else I suspect it is not an USB issue.

How long ago that HEAD was built? Could you get full dmesg? I don't
think that "PREVENT ALLOW MEDIUM REMOVAL" should cause device drop. "No
sense data present" also doesn't look right.

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

Re: Intel 82574 issue reported on Slashdot

[matt]

On 02/09/13 09:15, Johnny Eriksson wrote:
>> In all honesty.. The blog post (and your email) are basically
>> information free, they don't name names and provide no script
>> or downloadable code that will allow end users to check if they
>> are affected.
> A link with a little bit more information:
>
>   http://blog.krisk.org/2013/02/packets-of-death.html
>
>> Daniel O'Connor software and network engineer
> --Johnny
> ___
> 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"
>
Did anyone check to see if the Intel announcement had a 2 at 0x47f? :)

I do have a machine with these controllers that had a bridge "hang" in a
very odd fashion a while back, but it didn't repeat. It wasn't a
SuperMicro board, which is what some posters were saying were affected.

I would imagine a large ping packet (as used to test MTU) should
inoculate any affected interface if issued at boot, I don't think our
padding lines up with the problem. Once an interface sees a packet with
anything else at 0x47f, it's no longer affected, so there's a narrow
window of vulnerability in affected NICs.

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

some usb troubles

[Chagin Dmitry]

Hi all,

trying to run macbookpro10,1 on HEAD:

1) usb3.0 does not work at 9.1 and HEAD (r246587)
2) Between stable/9 and HEAD (r246587) we are lost uhid devices
(external keyboard and mouse) and umass. dmesg on the same hw can find here:

http://people.freebsd.org/~dchagin/macbookpro/dmesg.generic.stable9.txt
http://people.freebsd.org/~dchagin/macbookpro/dmesg.generic.HEAD.txt

pciconf:

http://people.freebsd.org/~dchagin/macbookpro/pciconf.txt

any help would be greatly apprecated.

-- 
Have fun!
chd


pgpX2XRXgWJHB.pgp
Description: PGP signature

Re: [patch] Userland DTrace

[Mark Johnston]

On Fri, Feb 08, 2013 at 04:04:38PM +, Matt Burke wrote:
> I've been spending some time trying to get the fasttrap provider to work
> on FreeBSD without panicing. I believe I have succeeded, at least to the
> point where it's no longer panicing.
> 
> There were two panic causes. The first was
> http://www.freebsd.org/cgi/query-pr.cgi?pr=165541 - the FreeBSD port of
> fasttrap.c caused ftp_rcount to be left >0. To fix this I've got rid of
> the early return and reverted to the opensolaris way.
> 
> A second panic then showed up intermittently when fasttrap_pid_cleanup_cb
> was run while something in userland had locks. Using sx_try_xlock calls
> has stopped the panics and shouldn't affect operation AFAICT.

I've run into this too. It can happen even when I'm not using DTrace
since fasttrap.ko is always loaded on my system. The problem is that
fasttrap_exec_exit() is called every time a process exits in this case;
the caller acquires dtrace_lock, and the panic occurs when a callout
thread tries to acquire the lock at the same time.

> 
> This is against r246454.
> 
> 
> Although this has fixed the panics for me, I'm finding a lot of stuff just
> isn't actually working, with dtrace and the traced process just chewing
> CPU. Truss on the dtrace shows a heck of a lot of ptrace() calls and I
> have no idea what the target is doing... CPU time is split 2:1
> dtrace:target

Another panic can occur with an INVARIANTS kernel if a DTrace victim
process forks. I've supplied a patch which fixes this for me here:
http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/171360

> 
> 
> Also noteworthy is the LOR on the first time you try to use the fasttrap
> provider: http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/165479
> 
> The lock order there seems right, so I'm guessing "something else" must
> have done it wrong first? How can I find out what the "something else"
> is?
> 
> 
> Thanks
> 
> 
> --- a/sys/cddl/contrib/opensolaris/uts/common/dtrace/dtrace.c
> +++ b/sys/cddl/contrib/opensolaris/uts/common/dtrace/dtrace.c
> @@ -7536,9 +7536,23 @@ dtrace_unregister(dtrace_provider_id_t id)
> return (EBUSY);
> }
> } else {
> +#if defined(sun)
> mutex_enter(&dtrace_provider_lock);
> mutex_enter(&mod_lock);
> mutex_enter(&dtrace_lock);
> +#else
> +   if (sx_try_xlock(&dtrace_provider_lock) == 0)
> +   return (EBUSY);
> +   if (sx_try_xlock(&mod_lock) == 0) {
> +   mutex_exit(&dtrace_provider_lock);
> +   return (EBUSY);
> +   }
> +   if (sx_try_xlock(&dtrace_lock) == 0) {
> +   mutex_exit(&mod_lock);
> +   mutex_exit(&dtrace_provider_lock);
> +   return (EBUSY);
> +   }
> +#endif
> }
>  
> /*
> --- a/sys/cddl/contrib/opensolaris/uts/common/dtrace/fasttrap.c
> +++ b/sys/cddl/contrib/opensolaris/uts/common/dtrace/fasttrap.c
> @@ -1116,23 +1116,28 @@ fasttrap_pid_disable(void *arg, dtrace_id_t id, void 
> *parg)
>  
> ASSERT(id == probe->ftp_id);
>  
> -   mutex_enter(&provider->ftp_mtx);
> -
> /*
>  * We won't be able to acquire a /proc-esque lock on the process
>  * iff the process is dead and gone. In this case, we rely on the
>  * provider lock as a point of mutual exclusion to prevent other
>  * DTrace consumers from disabling this probe.
>  */
> -   if ((p = pfind(probe->ftp_pid)) == NULL) {
> -   mutex_exit(&provider->ftp_mtx);
> -   return;
> +
> +#if defined(sun)
> +   if ((p = sprlock(probe->ftp_pid)) != NULL) {
> +   ASSERT(!(p->p_flag & SVFORK));
> +   mutex_exit(&p->p_lock);
> +   }
> +#else
> +   if ((p = pfind(probe->ftp_pid)) != NULL) {
> +   _PHOLD(p);
> +   PROC_UNLOCK(p);
> }
> -#ifdef __FreeBSD__
> -   _PHOLD(p);
> -   PROC_UNLOCK(p);
>  #endif
>  
> +   mutex_enter(&provider->ftp_mtx);
> +
> +
> /*
>  * Disable all the associated tracepoints (for fully enabled probes).
>  */
> @@ -1154,6 +1159,13 @@ fasttrap_pid_disable(void *arg, dtrace_id_t id, void 
> *parg)
> if (provider->ftp_retired && !provider->ftp_marked)
> whack = provider->ftp_marked = 1;
> mutex_exit(&provider->ftp_mtx);
> +
> +#if defined(sun)
> +   mutex_enter(&p->p_lock);
> +   sprunlock(p);
> +#else
> +   PRELE(p);
> +#endif
> } else {
> /*
>  * If the process is dead, we're just waiting for the
> @@ -1167,9 +1179,6 @@ fasttrap_pid_disable(void *arg, dtrace_id_t id, void 
> *parg)
> if (whack)
> fasttrap_pid_cleanup();
>  
> -#ifdef __FreeBSD__
> -   PRELE(p);
> -#endif
> if (!probe->ftp_enabled)
>  

Re: Intel 82574 issue reported on Slashdot

[CeDeROM]

On Sat, Feb 9, 2013 at 4:25 PM, CeDeROM  wrote:
> On Sat, Feb 9, 2013 at 3:44 PM, Christoph Moench-Tegeder
>  wrote:
>> ## O. Hartmann (ohart...@zedat.fu-berlin.de):
>>> We don't even have the tool tcpreplay in the ports mentioned in that BLOG.
>> It's in net-mgmt/tcpreplay.
>
> And I managed to build mentioned Ostinato packet crafting utility with
> no problem on my FreeBSD 9.1-RELEASE AMD64. If they provide package
> and release (which I already asked from the authors) I will make a
> port for this tool as well :-)

There it goes http://www.freebsd.org/cgi/query-pr.cgi?pr=175993 have fun! :-)

-- 
CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
___
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"

[dcha...@freebsd.org: some usb troubles]

[Chagin Dmitry]

Hi all,

trying to run HEAD on macbookpro10,1:

1) usb3.0 does not work at 9.1 and HEAD (r246587)
2) between stable/9 and HEAD (r246587) we are lost uhid devices
(external keyboard and mouse) and umass. dmesg on the same hw can be find here:

http://people.freebsd.org/~dchagin/macbookpro/dmesg.generic.stable9.txt
http://people.freebsd.org/~dchagin/macbookpro/dmesg.generic.HEAD.txt

pciconf: http://people.freebsd.org/~dchagin/macbookpro/pciconf.txt

any help would be greatly apprecated.

-- 
Have fun!
chd


pgpTaQ__nKjSt.pgp
Description: PGP signature

Re: [patch] Userland DTrace

[Andrey Zonov]

On 2/8/13 8:04 PM, Matt Burke wrote:
> I've been spending some time trying to get the fasttrap provider to work
> on FreeBSD without panicing. I believe I have succeeded, at least to the
> point where it's no longer panicing.
> 
> There were two panic causes. The first was
> http://www.freebsd.org/cgi/query-pr.cgi?pr=165541 - the FreeBSD port of
> fasttrap.c caused ftp_rcount to be left >0. To fix this I've got rid of
> the early return and reverted to the opensolaris way.
> 
> A second panic then showed up intermittently when fasttrap_pid_cleanup_cb
> was run while something in userland had locks. Using sx_try_xlock calls
> has stopped the panics and shouldn't affect operation AFAICT.
> 
> This is against r246454.
> 
> 
> Although this has fixed the panics for me, I'm finding a lot of stuff just
> isn't actually working, with dtrace and the traced process just chewing
> CPU. Truss on the dtrace shows a heck of a lot of ptrace() calls and I
> have no idea what the target is doing... CPU time is split 2:1
> dtrace:target
> 

Great!  This fixes panics for me too, but I still cannot get something
useful tracing and after detaching by ctrl+c my programs still segfaults.

Please look at one style comment below.

> 
> Also noteworthy is the LOR on the first time you try to use the fasttrap
> provider: http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/165479
> 
> The lock order there seems right, so I'm guessing "something else" must
> have done it wrong first? How can I find out what the "something else"
> is?
> 
> 
> Thanks
> 
> 
> --- a/sys/cddl/contrib/opensolaris/uts/common/dtrace/dtrace.c
> +++ b/sys/cddl/contrib/opensolaris/uts/common/dtrace/dtrace.c
> @@ -7536,9 +7536,23 @@ dtrace_unregister(dtrace_provider_id_t id)
> return (EBUSY);
> }
> } else {
> +#if defined(sun)
> mutex_enter(&dtrace_provider_lock);
> mutex_enter(&mod_lock);
> mutex_enter(&dtrace_lock);
> +#else
> +   if (sx_try_xlock(&dtrace_provider_lock) == 0)

s/sx_try_xlock/mutex_tryenter/

Look at sys/cddl/compat/opensolaris/sys/mutex.h

> +   return (EBUSY);
> +   if (sx_try_xlock(&mod_lock) == 0) {
> +   mutex_exit(&dtrace_provider_lock);
> +   return (EBUSY);
> +   }
> +   if (sx_try_xlock(&dtrace_lock) == 0) {
> +   mutex_exit(&mod_lock);
> +   mutex_exit(&dtrace_provider_lock);
> +   return (EBUSY);
> +   }
> +#endif
> }
>  
> /*
> --- a/sys/cddl/contrib/opensolaris/uts/common/dtrace/fasttrap.c
> +++ b/sys/cddl/contrib/opensolaris/uts/common/dtrace/fasttrap.c
> @@ -1116,23 +1116,28 @@ fasttrap_pid_disable(void *arg, dtrace_id_t id, void 
> *parg)
>  
> ASSERT(id == probe->ftp_id);
>  
> -   mutex_enter(&provider->ftp_mtx);
> -
> /*
>  * We won't be able to acquire a /proc-esque lock on the process
>  * iff the process is dead and gone. In this case, we rely on the
>  * provider lock as a point of mutual exclusion to prevent other
>  * DTrace consumers from disabling this probe.
>  */
> -   if ((p = pfind(probe->ftp_pid)) == NULL) {
> -   mutex_exit(&provider->ftp_mtx);
> -   return;
> +
> +#if defined(sun)
> +   if ((p = sprlock(probe->ftp_pid)) != NULL) {
> +   ASSERT(!(p->p_flag & SVFORK));
> +   mutex_exit(&p->p_lock);
> +   }
> +#else
> +   if ((p = pfind(probe->ftp_pid)) != NULL) {
> +   _PHOLD(p);
> +   PROC_UNLOCK(p);
> }
> -#ifdef __FreeBSD__
> -   _PHOLD(p);
> -   PROC_UNLOCK(p);
>  #endif
>  
> +   mutex_enter(&provider->ftp_mtx);
> +
> +
> /*
>  * Disable all the associated tracepoints (for fully enabled probes).
>  */
> @@ -1154,6 +1159,13 @@ fasttrap_pid_disable(void *arg, dtrace_id_t id, void 
> *parg)
> if (provider->ftp_retired && !provider->ftp_marked)
> whack = provider->ftp_marked = 1;
> mutex_exit(&provider->ftp_mtx);
> +
> +#if defined(sun)
> +   mutex_enter(&p->p_lock);
> +   sprunlock(p);
> +#else
> +   PRELE(p);
> +#endif
> } else {
> /*
>  * If the process is dead, we're just waiting for the
> @@ -1167,9 +1179,6 @@ fasttrap_pid_disable(void *arg, dtrace_id_t id, void 
> *parg)
> if (whack)
> fasttrap_pid_cleanup();
>  
> -#ifdef __FreeBSD__
> -   PRELE(p);
> -#endif
> if (!probe->ftp_enabled)
> return;
>  
> 


-- 
Andrey Zonov



signature.asc
Description: OpenPGP digital signature

Re: [patch] Userland DTrace

[Andrey Zonov]

On 2/10/13 1:47 AM, Mark Johnston wrote:
> On Fri, Feb 08, 2013 at 04:04:38PM +, Matt Burke wrote:
>> I've been spending some time trying to get the fasttrap provider to work
>> on FreeBSD without panicing. I believe I have succeeded, at least to the
>> point where it's no longer panicing.
>>
>> There were two panic causes. The first was
>> http://www.freebsd.org/cgi/query-pr.cgi?pr=165541 - the FreeBSD port of
>> fasttrap.c caused ftp_rcount to be left >0. To fix this I've got rid of
>> the early return and reverted to the opensolaris way.
>>
>> A second panic then showed up intermittently when fasttrap_pid_cleanup_cb
>> was run while something in userland had locks. Using sx_try_xlock calls
>> has stopped the panics and shouldn't affect operation AFAICT.
> 
> I've run into this too. It can happen even when I'm not using DTrace
> since fasttrap.ko is always loaded on my system. The problem is that
> fasttrap_exec_exit() is called every time a process exits in this case;
> the caller acquires dtrace_lock, and the panic occurs when a callout
> thread tries to acquire the lock at the same time.
> 
>>
>> This is against r246454.
>>
>>
>> Although this has fixed the panics for me, I'm finding a lot of stuff just
>> isn't actually working, with dtrace and the traced process just chewing
>> CPU. Truss on the dtrace shows a heck of a lot of ptrace() calls and I
>> have no idea what the target is doing... CPU time is split 2:1
>> dtrace:target
> 
> Another panic can occur with an INVARIANTS kernel if a DTrace victim
> process forks. I've supplied a patch which fixes this for me here:
> http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/171360
> 

I think you have to carefully ping George, and if he won't answer go
ahead with your patches.  Someone has to take care of userland dtrace.

-- 
Andrey Zonov



signature.asc
Description: OpenPGP digital signature

Re: HEAD memsticks broken? [USB/CAM Problems?]

[Joel Dahl]

On 09-02-2013 20:28, Alexander Motin wrote:
> How long ago that HEAD was built? Could you get full dmesg? I don't
> think that "PREVENT ALLOW MEDIUM REMOVAL" should cause device drop. "No
> sense data present" also doesn't look right.

As I mentioned earlier, I've tried several HEAD snapshots. This is booting a
r246472 memstick. I currently have no way to get a full dmesg, but I have
hand-typed the last parts below:

usbus0: 480Mbps High Speed USB v2.0
usbus1: 5.0Gbps Super Speed USB v3.0
usbus2: 480Mbps High Speed USB v2.0
ugen0.1:  at usbus0
uhub0:  on usbus0
ugen1.1: <0x1033> at usbus1
uhub1: <0x1033 XHCI root HUB, class 9/0, rev 3.00/1.00, addr 1> on usbus1
ugen2.1:  at usbus2
uhub2:  on usbus2
ses0 at ahciem0 bus 0 scbus3 target 0 lun 0
ses0:  SEMB S-E-S 2.00 device
ses0: SEMB SES Device
ada0 at ahcich0 bus 0 scbus0 target 0 lun 0
ada0:  ATA-8 SATA 2.x device
ada0: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes)
ada0: Command Queueing enabled
ada0: 152627MB (312581808 512 byte sectors: 1H 63S/T 16383C)
ada0: Previously was known as ad4
SMP: AP CPU #1 Launched!
SMP: AP CPU #3 Launched!
SMP: AP CPU #2 Launched!
Timecounter "TSC-low" frequency 1395499430 Hz quality 1000
WARNING: WITNESS option enabled, expect reduced performance.
uhub1: 4 ports with 4 removable, self powered
Root mount waiting for: usbus2 usbus0
uhub0: 3 ports with 3 removable, self powered
uhub2: 3 ports with 3 removable, self powered
ugen0.2:  at usbus0
uhub3:  on 
usbus0
ugen2.2:  at usbus2
uhub4:  on 
usbus2
Root mount wating for: usbus2 usbus0
ugen0.4:  at usbus0
ugen0.5:  at usbus0
ugen2.3:  at usbus2
umass0:  on usbus2
umass0: SCSI over BUlk-Only; quirks = 0x0100
umass0:5:0:-1: Attached to scbus5
da0 at umass-sim0 bus 0 scbus5 target 0 lun 0
da0:  Removable Direct Access SCSI-0 device
da0: 40.000MB/s transfers
da0: 3690MB (7557704 512 byte sectors: 255H 63S/T 470C)
(da0:umass-sim0:0:0:0): PREVENT ALLOW MEDIUM REMOVAL. CDB: 1e 00 00 00 01 00
(da0:umass-sim0:0:0:0): CAM status: Auto-Sense Retrieval Failed
(da0:umass-sim0:0:0:0): Error 5, Unretryable error
(da0:umass-sim0:0:0:0): PREVENT ALLOW MEDIUM REMOVAL. CDB: 1e 00 00 00 01 00
(da0:umass-sim0:0:0:0): CAM status: Auto-Sense Retrieval Failed
(da0:umass-sim0:0:0:0): Error 5, Unretryable error
(da0:umass-sim0:0:0:0): PREVENT ALLOW MEDIUM REMOVAL. CDB: 1e 00 00 00 01 00
(da0:umass-sim0:0:0:0): CAM status: Auto-Sense Retrieval Failed
(da0:umass-sim0:0:0:0): Error 5, Unretryable error
(da0:umass-sim0:0:0:0): PREVENT ALLOW MEDIUM REMOVAL. CDB: 1e 00 00 00 01 00
(da0:umass-sim0:0:0:0): CAM status: Auto-Sense Retrieval Failed
(da0:umass-sim0:0:0:0): Error 5, Unretryable error
(da0:umass-sim0:0:0:0): PREVENT ALLOW MEDIUM REMOVAL. CDB: 1e 00 00 00 01 00
(da0:umass-sim0:0:0:0): CAM status: Auto-Sense Retrieval Failed
(da0:umass-sim0:0:0:0): Error 5, Unretryable error
(da0:umass-sim0:0:0:0): SYNCHRONIZE CACHE(10). CDB: 35 00 00 00 00 00 00 00 00 
00
(da0:umass-sim0:0:0:0): CAM status: Auto-Sense Retrieval Failed
(da0:umass-sim0:0:0:0): Error 5, Unretryable error
(da0:umass-sim0:0:0:0): got CAM status 0x50
(da0:umass-sim0:0:0:0): fatal error, failed to attach to device
(da0:umass-sim0:0:0:0): lost device - 0 outstanding, 4 refs
(da0:umass-sim0:0:0:0): removing device entry
Root mount waiting for: usbus2
ugen2.4:  at usbus2
Trying to mount root from ufs:/dev/ufs/FreeBSD_Install [ro, noatime]...
mountroot: waiting for device /dev/ufs/FreeBSD_Install ...
Mounting from ufs:/dev/ufs/FreeBSD_Install failed with error 19.

mountroot>

I can probably take a couple of pictures of the entire dmesg, if that would be
of any interest.

-- 
Joel
___
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: geli(8) breaks after a couple hours of uptime

[Pawel Jakub Dawidek]

On Sat, Feb 09, 2013 at 06:00:53PM +0200, Andriy Gapon wrote:
> on 09/02/2013 17:04 Andrey Zonov said the following:
> > On 2/9/13 5:07 PM, Fabian Keil wrote:
> >>
> >> This would at least prevent the segfault.
> >>
> > 
> > I see two possibilities to get segfault:
> >   - no checking for result from memory allocation functions
> >   - too big stack
> > 
> > I have no found any broken memory allocation checking, but I found two
> > big objects on the stack.  One is buf[MAXPHYS] in eli_genkey_files() and
> > another is passbuf[MAXPHYS] in eli_genkey_passphrase().  If we change
> > these two to malloc(), then we can handle error from malloc(), print
> > some useful message and prevent segfault.
> 
> I'd rather do what Kostik suggested and Fabian mentioned: instead of
> mlockall(MCL_FUTURE) the code should mlock only the (explicitly designated)
> buffers that can contain sensitive data.

geli(8) almost exclusively deals with sensitive data. Even mlocking
MAXPHYS would fail with current limits, but this is bad idea.

With mlockall() I am sure I didn't miss anything - be it forgetting
about mlocking some buffer or zeroing it before munlock. I'm also sure
someone else who can modify geli(8) in the future won't miss anything
too.

geli(8) is relatively simple program, it doesn't allocate megabytes of
memory for different pruposes and just needs few pages for sensitive
data. As I said most of the memory it uses is for sensitive data.

The obvious problem is allocating MAXPHYS on the stack. This has to be
changed, especially that we may want to rise MAXPHYS in the future.

Other than that I expect thing would be tuned properly so that geli(8)
can work by default. I'm happy to use smaller buffers than MAXPHYS -
keyfiles are far smaller usually than 128kB, so there shouldn't be any
issue with this.

-- 
Pawel Jakub Dawidek   http://www.wheelsystems.com
FreeBSD committer http://www.FreeBSD.org
Am I Evil? Yes, I Am! http://tupytaj.pl


pgpjcefoSL7Mf.pgp
Description: PGP signature

7+ days of dogfood

[Steve Kargl]

In a long thread started by Peter Wemm on developers@, he described
the move/upgrade of the FreeBSD.org cluster to using FreeBSD-10.  A
part of his description included the need to test top-of-tree under
actual real-world conditions.  In his words, FreeBSD should "eat its
own dogfood."  The new installation on FreeBSD.org, of course, would
test FreeBSD-10 under (heavy) server load. 

So, I decided to test FreeBSD-10 under a user desktop condition.  In
so doing, I upgraded the circa August 2012 FreeBSD-current that ran
on my Dell Latitude D530 (which ran rock-solid) to top-of-tree.  This
included re-installing all ports under the pkgng paradigm.

I can only describe this experience as slowly shoving an icepick into
my ear channel.

Firefox segfaults after ~10 seconds.  Chrome gets stuck in a uwait
state and never becomes responsive.  Libreoffice displays its splash
screen and immediately segfaults.  Xorg does not start because it
cannot load the xf86-video-driver (unless it is explicitly recompiled
with /usr/bin/gcc).  Once I got Xorg working, there were a few silent
reboots (ie., nothing in /var/log/message, no core file, etc).

I spent a few days trying to hunt down the issues.  I rebult libc, 
libthr, libc++, and libcxxrt with debugging symbols and and firefox
and chrome under gdb751.  Nothing too informative to learn:

gdb751 /usr/local/share/chromium/chrome
...
(try going to seattle-times.com and get stuck)
...
(gdb) bt
#0  0x4d0323ab in _umtx_op_err () from /lib/libthr.so.3
#1  0x4d0274da in _thr_umtx_timedwait_uint () from /lib/libthr.so.3
#2  0x4d02d76f in _thr_sleep () from /lib/libthr.so.3
#3  0x4d0304b0 in ?? () from /lib/libthr.so.3
#4  0x4d030705 in pthread_cond_timedwait () from /lib/libthr.so.3
#5  0x086e7578 in ?? ()
#6  0x086f8d1b in ?? ()
#7  0x086f91c9 in ?? ()
#8  0x086f0c06 in ?? ()
#9  0x4d0255e6 in ?? () from /lib/libthr.so.3
#10 0x in ?? ()

gdb751 /usr/local/bin/firefox
(gdb) run
Starting program: /usr/local/bin/firefox 
[New LWP 100227]
[New Thread 48501080 (LWP 100227)]
[New Thread 4ec11500 (LWP 100245 StreamTrans #3)]

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 48501080 (LWP 100227)]
0x48c03295 in ?? () from /usr/local/lib/firefox/libxul.so
(gdb) bt
#0  0x48c03295 in ?? () from /usr/local/lib/firefox/libxul.so
#1  0x48aaf4b0 in ?? () from /usr/local/lib/firefox/libxul.so
Backtrace stopped: previous frame inner to this frame (corrupt stack?)

Unfortunately, trying to build firefox with debugging leads
reveals a broken port and building chrome with debugging leads
to a "file system full" issue (because it is a laptop with only
limited disk space).

Given that I need the laptop for work next week, I decide to rebuild
everything again.  Only this time I used the following /etc/make.conf:

  KERNCONF=MOBILE
  CPUTYPE?=core2

  #DISABLE_MAKE_JOBS="YES"

  WITHOUT_CLANG="YES"
  WITH_GCC="YES"
  WITHOUT_PROFILE="yes"

  FFLAGS = -O2 -pipe -march=native -mtune=native
  FFLAGS+= -funroll-loops -ftree-vectorize

  # added by use.perl 2013-02-07 20:58:29
  PERL_VERSION=5.14.2

I now have an almost functioning desktop environment on my laptop.
firefox, xorg, and chrome all work.  Sound has developed a pronounced
studder, that did not occur with the Aug 2012 freebsd-10.  Libreoffice
currently does not build, but that's not totally unexpected as compiling
libreoffice seems to be a hit-or-miss proposition. 

My conclusion:  on at least my not-so-new laptop, FreeBSD-10 can
be used in a desktop environment if one takes some care during the
installation.

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

building custom kernel on -current: unknown option "COMPAT_LINUX"

[Anton Shterenlikht]

This is on amd64 r246552

I added

options COMPAT_43
options COMPAT_LINUX
options COMPAT_LINUX32

to the kernel config,
following sys/amd64/conf/NOTES

On buildkernel I get:

unknown option "COMPAT_LINUX"

What am I missing?

Thanks

Anton
___
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: 7+ days of dogfood

[Anton Shterenlikht]

Date: Sat, 9 Feb 2013 16:07:23 -0800
From: Steve Kargl 
To: freebsd-current@freebsd.org
Subject: 7+ days of dogfood


In a long thread started by Peter Wemm on developers@, he described
the move/upgrade of the FreeBSD.org cluster to using FreeBSD-10.  A
part of his description included the need to test top-of-tree under
actual real-world conditions.  In his words, FreeBSD should "eat its
own dogfood."  The new installation on FreeBSD.org, of course, would
test FreeBSD-10 under (heavy) server load. 

So, I decided to test FreeBSD-10 under a user desktop condition.  In
so doing, I upgraded the circa August 2012 FreeBSD-current that ran
on my Dell Latitude D530 (which ran rock-solid) to top-of-tree.  This
included re-installing all ports under the pkgng paradigm.

I can only describe this experience as slowly shoving an icepick into
my ear channel.

*skip the details*

My experience is more positive.
I've r246552 on a Lenovo T61p amd64 laptop.

X works fine with Nvidia card with
nvidia-driver-304.64: x11/nvidia-driver
and with hald and dbus.

firefox-18.0.2,1: www/firefox
works fine (so far).
I haven't added flash yet.

sound seems fine, at least in
alienblaster-1.1.0_5: games/alienblaster

wireless works ok (I'm not sure, but
it seems to show some problems under load.
I need to investigate this further) with

device iwn # Intel 4965/1000/5000/6000 wireless NICs.
device iwn4965fw

All this with

# cat /etc/make.conf
SENDMAIL_CFLAGS+=   -I/usr/local/include -DSASL=2
SENDMAIL_LDFLAGS+=  -L/usr/local/lib
SENDMAIL_LDADD+=-lsasl2
WITH_PKGNG=yes
PERL_VERSION=5.16.2
#

Anton

___
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: 7+ days of dogfood

[Steve Kargl]

On Sat, Feb 09, 2013 at 04:07:23PM -0800, Steve Kargl wrote:
>
> Libreoffice currently does not build, but that's not totally
> unexpected as compiling libreoffice seems to be a hit-or-miss
> proposition. 
> 

laptop:root[201] cd 
/usr/ports/editors/libreoffice/work/libreoffice-core-3.6.5.2/l10ntools/
laptop:root[202] gmake
[ build LNK ] Executable/HelpIndexer
S=/usr/ports/editors/libreoffice/work/libreoffice-core-3.6.5.2 && 
O=/tmp/lobuild/solver/unxfbsdi.pro && W=/tmp/lobuild/workdir/unxfbsdi.pro &&  
mkdir -p $W/LinkTarget/Executable/ && g++46 
'-Wl,-z,origin,-rpath,$ORIGIN/../lib:$ORIGIN' -Wl,-rpath-link,$O/lib 
-Wl,-rpath-link,/lib:/usr/lib -Wl,-z,combreloc  -L$S/solenv/unxfbsdi/lib 
-L$O/lib -L$S/solenv/unxfbsdi/lib -L/usr/local/lib  -Wl,--hash-style=gnu  
-Wl,--dynamic-list-cpp-new -Wl,--dynamic-list-cpp-typeinfo 
-Wl,-Bsymbolic-functions
$W/CxxObject/l10ntools/source/help/HelpIndexer_main.o -Wl,--start-group  
-Wl,--end-group -Wl,--no-as-needed  -lexpat -lxslt  -lz -liconv -lm 
-L/usr/local/lib -lxml2   -L/usr/local/lib -lxml2   -L/usr/local/lib/db42 
-ldb-4.2  -L/usr/local/lib/ -lclucene-core   -lclucene-contribs-lib  -luno_sal 
-lhelplinkerlo -o $W/LinkTarget/Executable/HelpIndexer
/usr/local/lib/libclucene-core.so: undefined reference to `logl@GLIBCXX_3.4'
collect2: ld returned 1 exit status

Huh?  logl@GLIBCXX_3.4

laptop:kargl[189] cat > a.c
#include 
#include 

int  
main(void)
{
long double x;
x = (long double) M_PI;
printf("%Le %Le\n", x, logl(x));
return (0);
}
laptop:kargl[190] cc -o z a.c -lm && ./z
3.141593e+00 1.144730e+00
laptop:kargl[191] nm --dynamic z
 w _Jv_RegisterClasses
08049804 D __progname
08049818 A _end
 U _init_tls
 U atexit
08049814 B environ
 U exit
 U logl
 U printf

laptop:kargl[193] nm --dynamic /usr/lib/libm.so | grep logl
58f0 T logl

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

Re: building custom kernel on -current: unknown option "COMPAT_LINUX"

[Anton Shterenlikht]

From free...@edvax.de Sun Feb 10 00:29:36 2013

On Sun, 10 Feb 2013 00:18:06 GMT, Anton Shterenlikht wrote:
> This is on amd64 r246552
> 
> I added
> 
> options COMPAT_43
> options COMPAT_LINUX
> options COMPAT_LINUX32
> 
> to the kernel config,
> following sys/amd64/conf/NOTES
> 
> On buildkernel I get:
> 
> unknown option "COMPAT_LINUX"
> 
> What am I missing?

Do you also have those (from a working i386 system):

# Linux support
options COMPAT_LINUX# Enable Linux ABI emulation
options LINPROCFS   # Enable the linux-like proc 
filesystemsupport (requires COMPAT_LINUX and PSEUDOFS)
options LINSYSFS# Enable the linux-like sys 
filesystem support (requires COMPAT_LINUX and PSEUDOFS)
device  lindev
options COMPAT_AOUT # Enable i386 a.out binary 
support

(note PSEUDOFS is also needed)

No, I haven't added those.
Are these necessary to have
the linux binary compatibility?
The handbook only mentions COMPAT_LINUX.

Thanks

Anton
___
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: building custom kernel on -current: unknown option "COMPAT_LINUX"

[Anton Shterenlikht]

From free...@edvax.de Sun Feb 10 00:42:11 2013

On Sun, 10 Feb 2013 00:31:44 GMT, Anton Shterenlikht wrote:
>   From free...@edvax.de Sun Feb 10 00:29:36 2013
> 
>   On Sun, 10 Feb 2013 00:18:06 GMT, Anton Shterenlikht wrote:
>   > This is on amd64 r246552
>   > 
>   > I added
>   > 
>   > options COMPAT_43
>   > options COMPAT_LINUX
>   > options COMPAT_LINUX32
>   > 
>   > to the kernel config,
>   > following sys/amd64/conf/NOTES
>   > 
>   > On buildkernel I get:
>   > 
>   > unknown option "COMPAT_LINUX"
>   > 
>   > What am I missing?
> 
>   Do you also have those (from a working i386 system):
> 
>   # Linux support
>   options COMPAT_LINUX# Enable Linux ABI 
emulation
>   options LINPROCFS   # Enable the linux-like 
proc filesystemsupport (requires COMPAT_LINUX and PSEUDOFS)
>   options LINSYSFS# Enable the linux-like 
sys filesystem support (requires COMPAT_LINUX and PSEUDOFS)
>   device  lindev
>   options COMPAT_AOUT # Enable i386 a.out 
binary support
> 
>   (note PSEUDOFS is also needed)
> 
> No, I haven't added those.
> Are these necessary to have
> the linux binary compatibility?
> The handbook only mentions COMPAT_LINUX.

I think I had the same question some time ago and found
out that if those options are present, the Linux functionality
will build properly in the kernel. So I assume they are
required.

I removed COMPAT_LINUX, and only left

options COMPAT_43
options COMPAT_LINUX32

This seems enough to get flash
working with firefox, exactly as per
the handbook instructions.

Anton
___
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: 7+ days of dogfood

[Erich Dollansky]

Hi,

On Sat, 9 Feb 2013 16:07:23 -0800
Steve Kargl  wrote:

> actual real-world conditions.  In his words, FreeBSD should "eat its
> own dogfood."  The new installation on FreeBSD.org, of course, would

I am on dog food since last May/June. How should I phrase it? Every can
tastes different. Most cans have a perfect taste but some cans are
really off.

So, when I see a bad can, I go back to my old can, wait a day and get
me then a new can. This is then - most likely - good again.

This is the real reason why it is not possible to run important
machines on dog food. If one can is bad, the machine is down.

As FreeBSD.org sits next to the canning machine, it can run on dog food.

Erich
___
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: building custom kernel on -current: unknown option "COMPAT_LINUX"

[Polytropon]

On Sun, 10 Feb 2013 00:18:06 GMT, Anton Shterenlikht wrote:
> This is on amd64 r246552
> 
> I added
> 
> options COMPAT_43
> options COMPAT_LINUX
> options COMPAT_LINUX32
> 
> to the kernel config,
> following sys/amd64/conf/NOTES
> 
> On buildkernel I get:
> 
> unknown option "COMPAT_LINUX"
> 
> What am I missing?

Do you also have those (from a working i386 system):

# Linux support
options COMPAT_LINUX# Enable Linux ABI emulation
options LINPROCFS   # Enable the linux-like proc 
filesystemsupport (requires COMPAT_LINUX and PSEUDOFS)
options LINSYSFS# Enable the linux-like sys filesystem 
support (requires COMPAT_LINUX and PSEUDOFS)
device  lindev
options COMPAT_AOUT # Enable i386 a.out binary support

(note PSEUDOFS is also needed)



-- 
Polytropon
Magdeburg, Germany
Happy FreeBSD user since 4.0
Andra moi ennepe, Mousa, ...
___
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: building custom kernel on -current: unknown option "COMPAT_LINUX"

[Polytropon]

On Sun, 10 Feb 2013 00:31:44 GMT, Anton Shterenlikht wrote:
>   From free...@edvax.de Sun Feb 10 00:29:36 2013
> 
>   On Sun, 10 Feb 2013 00:18:06 GMT, Anton Shterenlikht wrote:
>   > This is on amd64 r246552
>   > 
>   > I added
>   > 
>   > options COMPAT_43
>   > options COMPAT_LINUX
>   > options COMPAT_LINUX32
>   > 
>   > to the kernel config,
>   > following sys/amd64/conf/NOTES
>   > 
>   > On buildkernel I get:
>   > 
>   > unknown option "COMPAT_LINUX"
>   > 
>   > What am I missing?
> 
>   Do you also have those (from a working i386 system):
> 
>   # Linux support
>   options COMPAT_LINUX# Enable Linux ABI emulation
>   options LINPROCFS   # Enable the linux-like proc 
> filesystemsupport (requires COMPAT_LINUX and PSEUDOFS)
>   options LINSYSFS# Enable the linux-like sys 
> filesystem support (requires COMPAT_LINUX and PSEUDOFS)
>   device  lindev
>   options COMPAT_AOUT # Enable i386 a.out binary 
> support
> 
>   (note PSEUDOFS is also needed)
> 
> No, I haven't added those.
> Are these necessary to have
> the linux binary compatibility?
> The handbook only mentions COMPAT_LINUX.

I think I had the same question some time ago and found
out that if those options are present, the Linux functionality
will build properly in the kernel. So I assume they are
required.



-- 
Polytropon
Magdeburg, Germany
Happy FreeBSD user since 4.0
Andra moi ennepe, Mousa, ...
___
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: building custom kernel on -current: unknown option "COMPAT_LINUX"

[ill...@gmail.com]

On 9 February 2013 20:26, Anton Shterenlikht  wrote:

>
> I removed COMPAT_LINUX, and only left
>
> options COMPAT_43
> options COMPAT_LINUX32
>

>From /usr/src/sys/amd64/conf/NOTES (9.1-RELEASE):

# Enable Linux ABI emulation
#XXX#optionsCOMPAT_LINUX

# Enable 32-bit Linux ABI emulation (requires COMPAT_43 and
COMPAT_FREEBSD32)
options COMPAT_LINUX32

I think I first ran up against this when I moved to 9.0 some
time ago, but yes, amd64 uses a different kernel config
option than i386 for linux compat.

I tend to leave it as a module & load it if I perchance
need it. This also allows rebuilding & reloading the
modules without a reboot, should it need it.  The
modules seems to build fine without having to
fiddle about with kernel config jiggerypokey.

-- 
--
___
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: 7+ days of dogfood

[Ian FREISLICH]

Steve Kargl wrote:
> Firefox segfaults after ~10 seconds.  Chrome gets stuck in a uwait
> state and never becomes responsive.  Libreoffice displays its splash
> screen and immediately segfaults.  Xorg does not start because it
> cannot load the xf86-video-driver (unless it is explicitly recompiled
> with /usr/bin/gcc).  Once I got Xorg working, there were a few silent
> reboots (ie., nothing in /var/log/message, no core file, etc).

>   KERNCONF=MOBILE
>   CPUTYPE?=core2
> 
>   #DISABLE_MAKE_JOBS="YES"
> 
>   WITHOUT_CLANG="YES"
>   WITH_GCC="YES"

Shouldn't this be "WITHOUT_CLANG_IS_CC=yes"?

I must say that my experience of -CURRENT dogfood has been entirely
different.  I can't remember the last time I didn't run -CURRENT
as my desktop.  I also have run -CURRENT in production for the last
several years although it's a ruating load, not a compute load.

Others might not agree with what I'm about to say.
1. WITHOUT_CLANG_IS_CC=yes
   I don't think clang is ready for prime time in FreeBSD, or FreeBSD
   isn't ready to use clang in prime time.  I got a new laptop (ASUS
   UX31A) and found that a lot of the ports I needed to install
   didn't compile or core dumped.  (Sorry I didn't report these to
   the project).
   This option sorted that problem out.  However you will need to
   rebuild everything including world and kernel with gcc before
   you start building ports with gcc or you will still have problems.

2. MALLOC_PRODUCTION=yes
   Maybe it's the placebo effect.  Binaries are smaller in memory
   and "things seem faster"

3. xorg, firefox18, WITH_NEW_XORG=yes, WITH_KMS=yes
   I've found that HAL is a waste of time with X.  It's hit and
   miss when it comes to reporting hardware to X, better to just
   not use it.
   Xorg has always worked well for me.  My new laptop required that
   I use the new xorg port to get anything resembling decent
   performance.  Getting KMS to work was a bit unsettling and X only
   seems to work when it's launched by hand from a real terminal.
   xdm won't start from /etc/ttys with NEW_XORG, but I can live
   with that.
   I've just upgraded firefox-18.0 to firefox-18.0.2 without a
   hitch.  I have flash working without a hitch.  Even the acroread
   plugin works for viewing PDFs in browser.

4. Sound.
   I've had less success with this, but I think my problems would
   be the same on 8 and 9.  It seems common for HDA these days to
   put the useful sound bits on different devices:

pcm0:  (play/rec) default
pcm1:  (play)
pcm2:  (play)

   So my headphone jack doesn't work.  On my other laptor, the
   builtin mic doesn't work because it's on pcm1 and there's not a
   way to make pcm1 the default input device and pcm0 the default
   output device.
   I need to spend some time with a verbose boot and see if I can
   figure out the audio routing.

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: 7+ days of dogfood

[Tim Kientzle]

On Feb 9, 2013, at 10:33 PM, Ian FREISLICH wrote:

> 2. MALLOC_PRODUCTION=yes
>   Maybe it's the placebo effect.  Binaries are smaller in memory
>   and "things seem faster"

There have been significant improvements in this area
very recently.   Please give it another try without this
setting and let us know.

Tim

___
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: 7+ days of dogfood

[Steve Kargl]

On Sun, Feb 10, 2013 at 08:33:25AM +0200, Ian FREISLICH wrote:
> Steve Kargl wrote:
> > Firefox segfaults after ~10 seconds.  Chrome gets stuck in a uwait
> > state and never becomes responsive.  Libreoffice displays its splash
> > screen and immediately segfaults.  Xorg does not start because it
> > cannot load the xf86-video-driver (unless it is explicitly recompiled
> > with /usr/bin/gcc).  Once I got Xorg working, there were a few silent
> > reboots (ie., nothing in /var/log/message, no core file, etc).
> 
> >   KERNCONF=MOBILE
> >   CPUTYPE?=core2
> > 
> >   #DISABLE_MAKE_JOBS="YES"
> > 
> >   WITHOUT_CLANG="YES"
> >   WITH_GCC="YES"
> 
> Shouldn't this be "WITHOUT_CLANG_IS_CC=yes"?

I haven't looked at the difference, but I would assume
that WITHOUT_CLANG doesn't waste time building clang
while WITHOUT_CLANG_IS_CC builds clang but doesn't
install it as cc.

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

Re: geli(8) breaks after a couple hours of uptime

[Andriy Gapon]

on 10/02/2013 01:35 Pawel Jakub Dawidek said the following:
> geli(8) almost exclusively deals with sensitive data. Even mlocking
> MAXPHYS would fail with current limits, but this is bad idea.
> 
> With mlockall() I am sure I didn't miss anything - be it forgetting
> about mlocking some buffer or zeroing it before munlock. I'm also sure
> someone else who can modify geli(8) in the future won't miss anything
> too.

Well, the geli is not such a complex program really.  It seems to use only two
or so buffers for sensitive data.  As far as I can see geli deals only with some
key management (reading keys, generating key from key material, etc). There is
definitely no need to mlock the code, etc.

> geli(8) is relatively simple program, it doesn't allocate megabytes of
> memory for different pruposes and just needs few pages for sensitive
> data. As I said most of the memory it uses is for sensitive data.

Right, except for code (from geli and from shared libraries) and other stuff
that is really not sensitive at all.

> The obvious problem is allocating MAXPHYS on the stack. This has to be
> changed, especially that we may want to rise MAXPHYS in the future.

Yes, I do not see any relation between what geli does and MAXPHYS.

> Other than that I expect thing would be tuned properly so that geli(8)
> can work by default. I'm happy to use smaller buffers than MAXPHYS -
> keyfiles are far smaller usually than 128kB, so there shouldn't be any
> issue with this.

I think that PAGE_SIZE (or at most a small multiple of it) should be sufficient.
I don't think that we currently have (or expect to see in the near future)
algorithms where keys with more than 4096 size provide any additional security.

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