similar to: FreeBSD 7.1 svn186551

On 7/28/2016 3:41 PM, Fawzy Ibrahim wrote: > LSI SATA MEGARAID 95Q9 afaik, the megaraid cards are mostly all SAS, which support SATA drives, except very old ones were SCSI. Ok, I do see they had a series of MegaRAID SATA 150-xx and 300-xx cards, these were 64 bit PCI or PCI-X cards. 95Q9 does not appear to be a valid card number, 9240, 9260, 9280 are some pci-express SAS MegaRaid

John R Pierce wrote: > On 7/26/2016 10:20 AM, Fawzy Ibrhim wrote: >> I want to install Centos 7 latest build on NEC Server 5800/120b-2. >> >> The installation wizard fails to detect the storage connected to LSI >> SATA MegaRaid PCI. > > which megaraid card? they've made quite a lot. lspci will list the > card type... > > linux will only see storage

Normally the FreeBSD Project tries very hard to avoid ABI breakage in "Stable Branches". However occasionally the fix for a bug can not be implemented without ABI breakage, and it is decided that the fix warrants the impact of the ABI breakage. We have one of those situations coming along for RELENG_7 (what will become FreeBSD 7.1). The ABI breakage should only impact kernel modules

Hi, On an 8.2 box, I run freebsd-update -r 8.3-RELEASE upgrade I am getting hundreds of files with "conflicts" like: <<<<<<< current version # $FreeBSD: src/etc/auth.conf,v 1.6.32.1.4.1 2010/06/14 02:09:06 kensmith Exp $ ======= # $FreeBSD: src/etc/auth.conf,v 1.6.32.1.8.1 2012/03/03 06:15:13 kensmith Exp $ >>>>>>> 8.3-RELEASE ... which is

The first release candidate of the 9.1-RELEASE release cycle is now available on the FTP servers for amd64, i386, and powerpc64. The MD5/SHA256 checksums are at the bottom of this message. The ISO images and, for architectures that support it, the memory stick images are available here: ftp://ftp.freebsd.org/pub/FreeBSD/releases/ISO-IMAGES/9.1/ (or any of the FreeBSD mirror sites). Current

Hey there.. I was wondering if anyone could share experiences they have had with the Intel ICH10R SATA controller? I tried looking around but all I could find were RAID references, I have no interest in using the RAID functionality just basic SATA JBOD. Wondering if there are any gotchas for performance, drivers, quality etc. I normally don't touch anything that is not hardware RAID though

Greetings, I''m attempting to do gfx_passthru with the primary graphics adapter (03:00.0), passing it to a guest. I can unbind it from the host but when I fire up the guest OS my monitor loses signal from the graphics card and that''s that. The GFX card is dual DVI, I''ve tried both slots. Host is Linux 2.6.32.14-1.2.105.xendom0.fc12.x86_64, Guest is Windows 7. PC is an

# lspci -nn 00:00.0 Host bridge [0600]: Intel Corporation 5520 I/O Hub to ESI Port [8086:3406] (rev 22) 00:01.0 PCI bridge [0604]: Intel Corporation 5520/5500/X58 I/O Hub PCI Express Root Port 1 [8086:3408] (rev 22) 00:03.0 PCI bridge [0604]: Intel Corporation 5520/5500/X58 I/O Hub PCI Express Root Port 3 [8086:340a] (rev 22) 00:05.0 PCI bridge [0604]: Intel Corporation 5520/X58 I/O Hub PCI

David, (and everyone else) I am forced to do some maintenance work on a fairly old LLVM branch (likely based on release 3.1) that among other issues has a major problem with memory leak somewhere around DWARF debug support. In fact customer is unable to build with -g at all - simply running out of memory on their project... I seem to remember that there has been a major fix related to it,

On 7/30/2016 6:56 AM, Fawzy Ibrhim wrote: > # lspci -nn > 00:00.0 Host bridge [0600]: Intel Corporation 5520 I/O Hub to ESI Port [8086:3406] (rev 22) > 00:01.0 PCI bridge [0604]: Intel Corporation 5520/5500/X58 I/O Hub PCI Express Root Port 1 [8086:3408] (rev 22) > 00:03.0 PCI bridge [0604]: Intel Corporation 5520/5500/X58 I/O Hub PCI Express Root Port 3 [8086:340a] (rev 22) >

David, Thanks for the quick response... No, at this point I am just getting into the issue... I assume it is a leak, but no clear proof yet. I was hoping it was an obvious thing since I recall a discussion about it a while ago... but maybe I am just confused. Was your work for compressing DWARF data motivated by a certain inefficiency in debug info representation? Did it result in

Hi, since samba 2.2.4 (I use the prebuilt Mandrake cooker RPMs) I got the following problem on authorizing or changing a password using 'smbpasswd'. Ever user is rejected, even if he uses the correct password and in my logs the following error messages appear: ------------------------- May 11 12:31:22 pc1 smbd[18130]: [2002/05/11 12:31:22, 0] passdb/pdb_ldap.c:ldap_connect_system(159)

Hello, I''m hoping someone may be able to push us in the right direction. I''m trying to get one of our products to work with the current branch of Xen (4.0/4.0.0) but I''m hitting a problem. We are currently using Xen 3.3.2 on a Sun Blade 600 chassis (with x6270 blades) this works great. But when we upgrade to Xen 4.0/4.0.1 we get the following message when

I obtain this error when booting (xen/stable-2.6.31.x|xen/master) on Xen 3.4.2 x86_64 xen_major : 3 xen_minor : 4 xen_extra : .2 I had no errors with the same kernel, version of the day 2010-03-03 To compile the kernel i use this configuration " http://pasik.reaktio.net/xen/pv_ops-dom0-debug/config-2.6.31.6-pvops-dom0-xen-master-x86_64 "

I am seeing some problems when using the Powerware 5115 UPS when connected to the Patsburg USB controller and would like to know if anyone has a solution. The symptom is that PING messages sent to the bcmxcp_usb driver take as long as 25 seconds to complete. The configuration is a Romley patform (a.k.a., Sandy Bridge + Patsburg) running Debian 6 with 2.6.39 kernel with NUT 2.6.4 in which the

On Dec 16, 2014, at 9:45 AM, Frantz de Germain <frantz at info.univ-angers.fr> wrote: > Bye the way I just realize that I can't retrieve the ups.load, among other > thing :-( To the best of my knowledge, Microlink is not supported by any third-party tools (including NUT), but some variables are exposed via standard USB HID. Apparently, ups.load is not one of them. Your UPS might

Thanks Eric, They are doing LTO build but with some custom modifications (think a library at a time as opposed to a whole program). I must admit, it is a rather large application as well, so as expected, any inefficiencies are multiplied greatly. >From little that I have seen so far, it looks like debug metadata for an IR object linger behind once the object itself is eliminated (optimized).

What was the first target for LLVM? Tia. Reed

Hi Reed, I think it was SPARC, feel free to correct me though :) Regards, Tilmann On Apr 15, 2013, at 11:21 AM, reed kotler <rkotler at mips.com> wrote: > What was the first target for LLVM? > > Tia. > > Reed > > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >

Le Tue, 16 Dec 2014 15:36:29 +0100 Frantz de Germain <frantz at info.univ-angers.fr> ?crivait: > Hello, > > I'm testing an APC SMT3000RMI2U connected to an USB port with Nut 2.7.2. I've > got the message : > > "interrupt pipe disabled (add 'pollonly' flag to 'ups.conf' to get rid of this message)" > > I've been looking for