RE: Install or add printer HP Laser Jet Pro MFP M125nw
Hi Gabriel. The LaserJet Pro MFP M125nw is a PCLm printer, where the computer is responsible for rasterising the job and sending the raster to the printer. It lacks the PCL6 support found in more expensive HP laser printers with full feature formatters that gives them broad *BSD compatibility. I have some doubts that you will find a way to use a PCLm printer with FreeBSD. This thread might be more appropriate in freebsd-questions. With best wishes, David -- David Wood da...@wood2.org.uk ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: mfi(4) patch to add MSI-X support, possibly address command timeouts
Dear John (and freebsd-stable), In message 201108311334.10804@freebsd.org, John Baldwin j...@freebsd.org writes I'd like some folks to test a patch to the mfi(4) driver that may help to address issues several folks have reported. The patch does two things, first it adds some dummy reads of PCI registers when checking device status in the interrupt handler to flush the writes to ACK interrupts. The Linux megaraid-sas driver uses this approach and some folks have tested a patch from Scott Long which had a somewhat similar effect. Second, it enables the use of MSI-X interrupts for many newer devices. I've installed this patch on my Dell PowerEdge 2950 III with a PERC 6/i controller, which is running 8.2-RELEASE. So far all is working well. Is there any hope of MSI-X support for this device? It's 0x0060 - a SAS1078R - so is deliberately excluded from MSI-X by this patch. The system appears capable of MSI-X operation, but there might be a silicon bug I'm not aware of or extra code needed that is not provided by this patch. With best wishes, David -- David Wood da...@wood2.org.uk ___ 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: Serial multiport error Oxford/Startech PEX2S952
Hi Greg, In message 20110824070826.gk92...@core.byshenk.net, Greg Byshenk free...@byshenk.net writes On Mon, Aug 22, 2011 at 11:59:11AM +0100, David Wood wrote: In message 20110822094756.gj92...@core.byshenk.net, Greg Byshenk free...@byshenk.net writes It doesn't seem to matter; both cuau?.lock and cuau?.init produce the error (for both ports), and cuau? itself remains a no-op. You could try hint.uart.2.baud=115200 in /boot/device.hints - making the relevant changes to port number and speed according to your needs. This does not help; speed remains set to 9600. It was worth a go. Now that I can see that the card is working (at least minimally), it begins to look as if there might be a problem somewhere in 9.x. I'll try to install 8.x and see if the results are different. It will be interesting to see if there is a difference between 8.x and 9.x. Yes, there is. Using 8-STABLE (with sources from 17 August 2011) and inbuilt puc, the controller works as expected. It defaults to 9600, but setting the speed on the cuaa?.lock and cuaa?.init devices works. Interestingly, setting the speed in device.hints does _not_ work. It could be that setting speed in /boot/device.hints only works with ports directly handled by uart(4), not ports that uart(4) handles via puc(4). As 8-STABLE works, the support code I wrote and contributed works for your card, which is encouraging. So, it appears that there is something wrong (or at least different) with 9.x The best course of action is likely to be bringing up this problem on freebsd-current (as 9.x is not yet -stable) and filing a PR, noting the regression between 8-STABLE and 9-BETA. I'm fairly sure that the problem is likely to be in uart(4) or in something on which uart(4) rests, such as the tty layer. Even in 9-BETA puc(4) appears to be doing its job of identifying and configuring the ports before invoking uart(4) - so puc(4) doesn't appear to be to blame. Doing some poking around, I see that, in 9.x, termios.h is not included in dev/uart/uart_core.c and dev/uart/uart_tty.c. While it is included under 8.x. The commit logs for HEAD show that the inclusion of termios headers was removed as unnecessary (see r199872). I doubt that the problem is merely a missing header, not least as missing headers normally result in compilation failure. The isn't a terminal error you are getting indicates that the attempt to call tcgetaddr(3) on a file descriptor opened on the device is failing. Unfortunately, I am not familiar enough with the tty code to understand why that call is failing on 9.x. If posting on freebsd-current and filing a PR don't produce an answer, ed@ or kib@ may be able to throw some light. Those two committers are responsible for most of the relevant code, especially the tty layer. It may also be interesting to try 9.x on a machine with a serial port that operates directly with uart(4). Does stty(4) throw up isn't a terminal errors against the .init and .lock devices relating to those ports? I would try this myself, but am very short of time at present. Though there is probably little more that I can add, please keep me cc'd on all relevant e-mails, especially as I do not follow freebsd-current. With best wishes, David -- David Wood da...@wood2.org.uk ___ 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: Serial multiport error Oxford/Startech PEX2S952
Hi Greg,
In message 20110822083336.gi92...@core.byshenk.net, Greg Byshenk
free...@byshenk.net writes
On Mon, Aug 22, 2011 at 12:20:33AM +0200, Greg Byshenk wrote:
puc0: Oxford Semiconductor OXPCIe952 UARTs mem
0xf9dfc000-0xf9df,0xfa00-0xfa1f,0xf9e0-0xf9ff irq
30 at device 0.0 on pci4
puc0: 2 UARTs detected
uart2: 16950 or compatible at port 1 on puc0
uart3: 16950 or compatible at port 2 on puc0
This indicates that the puc(4) code is working correctly - it recognises
the board, reads via one of the BARs to confirm there are two UARTs,
initialises both UARTs to 16950 mode, then hands off these ports to
uart(4).
I'll follow up tomorrow. Thanks.
Following up:
It appears that indeed, the options COM_MULTIPORT is unnecessary
for 9-BETA; I've rebuilt the kernel without it, and the card is
still recognized, along with the ports.
That's what I expected. The only line needed is device puc. I have no
idea why this can't be included in GENERIC, especially as puc(4) doesn't
work as a module (no drivers are attached to the ports on the puc
board).
But all it not as it should be. I still can't set the speed on the
card.
# stty -f /dev/cuau2.init speed 115200 crtscts
stty: /dev/cuau2.init isn't a terminal
#
And setting speed on the device itself remains a no-op:
# stty -f /dev/cuau2 speed 115200 crtscts
9600
#
That said, the card -does- seem to work, at least at some level.
With the speed issue pointed out, I set the connection on the
other end to 9600, and then it works. But I'd really like it to
be faster than that (it's just a serial console, so we could
probably live with 9600, though we wouldn't like it).
If there is reason to think that this could be a 9.x issue,
then I could try going to 8.x.
My earlier instructions omitted mention of the lock, which is really
needed if you want to force a particular speed
On 8.2:
[root@manganese ~]# PORT='/dev/cuau5' ; OPTIONS='speed 115200 crtscts' ;
stty -f ${PORT}.lock 0 ; stty -f ${PORT}.init ${OPTIONS} /dev/null ;
stty -f ${PORT}.lock 1 ; stty -f ${PORT}
speed 115200 baud;
lflags: echoe echoke echoctl
oflags: tab0
cflags: cs8 -parenb crtscts
[root@manganese ~]# cu -l cuau5
Connected
ATI4
U.S. Robotics 56K FAX EXT Settings...
B0 E1 F1 L2 M1 Q0 V1 X4 Y1
SPEED=115200 PARITY=N WORDLEN=8
DIAL=TONEOFF LINE CID=1
A3 B1 C1 D2 H2 I2 K1
M4 N0 R1 S0 T5 U0 Y1
S00=000 S01=000 S02=043 S03=013 S04=010 S05=008 S06=004
S07=060 S08=002 S09=006 S10=014 S11=072 S12=050 S13=000
S15=000 S16=000 S18=000 S19=000 S21=010 S22=017 S23=019
S25=005 S27=001 S28=008 S29=020 S30=000 S31=128 S32=002
S33=000 S34=000 S35=000 S36=014 S38=000 S39=012 S40=000
S41=004 S42=000
LAST DIALLED #:
OK
~
[EOT]
[root@manganese ~]# PORT='/dev/cuau5' ; OPTIONS='speed 38400 crtscts' ;
stty -f ${PORT}.lock 0 ; stty -f ${PORT}.init ${OPTIONS} /dev/null ;
stty -f ${PORT}.lock 1 ; stty -f ${PORT}
speed 38400 baud;
lflags: echoe echoke echoctl
oflags: tab0
cflags: cs8 -parenb crtscts
[root@manganese ~]# cu -l cuau5
Connected
ATI4
U.S. Robotics 56K FAX EXT Settings...
B0 E1 F1 L2 M1 Q0 V1 X4 Y1
SPEED=38400 PARITY=N WORDLEN=8
DIAL=TONEOFF LINE CID=1
A3 B1 C1 D2 H2 I2 K1
M4 N0 R1 S0 T5 U0 Y1
S00=000 S01=000 S02=043 S03=013 S04=010 S05=008 S06=004
S07=060 S08=002 S09=006 S10=014 S11=072 S12=050 S13=000
S15=000 S16=000 S18=000 S19=000 S21=010 S22=017 S23=019
S25=005 S27=001 S28=008 S29=020 S30=000 S31=128 S32=002
S33=000 S34=000 S35=000 S36=014 S38=000 S39=012 S40=000
S41=004 S42=000
LAST DIALLED #:
OK
~
[EOT]
This is one of my OXPCIe954 ports - the modem on that port identifies
the speed it is being talked to in the ATI4 output.
If this is a 9.x issue, it seems more likely to be in the uart(4) code -
though I haven't been following development. If you are getting nowhere
with 9.x, can you try with 8.x? stable/8 might be the best choice, as
the necessary pucdata.c changes postdates 8.2-RELEASE. That said, I
patch 8.2-RELEASE on my machine, choosing to keep things conservative.
I look forward to your feedback.
With best wishes,
David
--
David Wood
da...@wood2.org.uk
___
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: Serial multiport error Oxford/Startech PEX2S952
Dear Greg, In message 20110822094756.gj92...@core.byshenk.net, Greg Byshenk free...@byshenk.net writes It doesn't seem to matter; both cuau?.lock and cuau?.init produce the error (for both ports), and cuau? itself remains a no-op. You could try hint.uart.2.baud=115200 in /boot/device.hints - making the relevant changes to port number and speed according to your needs. Now that I can see that the card is working (at least minimally), it begins to look as if there might be a problem somewhere in 9.x. I'll try to install 8.x and see if the results are different. It will be interesting to see if there is a difference between 8.x and 9.x. I'll followup again when I have something to report. I look forward to further feedback. With best wishes, David -- David Wood da...@wood2.org.uk ___ 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: Serial multiport error Oxford/Startech PEX2S952
Hi Greg,
I wrote and contributed the support code for the OXPCIe95x serial chips
- and just happened to notice your report.
In message 20110821154249.ge92...@core.byshenk.net, Greg Byshenk
free...@byshenk.net writes
I'm having a problem with a StarTech PEX2S952 dual-port serial
card.
I believe that it should be supported, as it has this entry in
pucdata.c
[...]
{ 0x1415, 0xc158, 0x, 0,
Oxford Semiconductor OXPCIe952 UARTs,
DEFAULT_RCLK * 0x22,
PUC_PORT_NONSTANDARD, 0x10, 0, -1,
.config_function = puc_config_oxford_pcie
},
[...]
It should be supported. The OXPCIe952 is more awkward to support than
the OXPCIe954 and OXPCIe958 because it can be configured in so many
different ways by the board manufacturer. However, 0xc158 is
configuration that is identical in arrangement as the larger chips, so
is the configuration I'm most confident of. I've just double-checked the
data sheets, and can't see any relevant differences between 0xc158
OXPCIe952 and the OXPCIe954 I tested the code with.
I use my OXPCIe954 board on FreeBSD 8.2, and have had success reports
from other OXPCIe954 and OXPCIe958 board users (including someone with a
16 port board based on dual OXPCIe958s). I have yet to try FreeBSD 9.x
on my hardware.
And, while it is recognized at boot -- after adding
device puc
options COM_MULTIPORT
I'm 99% certain that options COM_MULTIPORT relates to the old sio(4)
code - I certainly don't need it on 8.x. Does it make any difference if
you delete that line and just leave device puc?
to my kernel, it doesn't seem to be working. The devices '/dev/cuau2'
and '/dev/cuau3' show up, and I can connect to them, but they don't
seem to pass any traffic. If I connect to the serial console of
another machine (one that I know for certain is working), I get
nothing at all.
Have you remembered to set the speed (and other relevant options) on the
.init devices? This is a feature (or is it a quirk) of the uart(4)
driver that catches many people out. Setting options on the base device
is normally a no-op.
For example, if the remote device on /dev/cuau2 operates at 115200 bps
with hardware handshaking, try:
stty -f /dev/cuau2.init speed 115200 crtscts
One frustrating aspect of adding puc(4) support for many devices is that
you can't be certain of the clock rate multiplier - the same device can
crop up on a different manufacturer's board with a different multiplier.
This problem doesn't occur with the OXPCIe95x devices as they derive
their 62.5MHz UART clock from the PCI Express clock. Consequently, the
problem can't be that your board inadvertently operating the UARTs at
the wrong speed.
I suspect (?) that it may not be recognized as the proper card. Boot
and pciconf messages are:
puc0: Oxford Semiconductor OXPCIe952 UARTs mem
0xf9dfc000-0xf9df,0xfa00-0xfa1f,0xf9e0-0xf9ff irq
30 at device 0.0 on pci4
That is correct. Are there any more lines afterwards - especially one
giving the number of UARTs detected? That line is crucial, as, on these
chips, the number of UARTs has to be read from configuration space
because you can slave two chips together.
My OXPCIe954 board is recognised thus (FreeBSD 8.2 amd64):
puc0: Oxford Semiconductor OXPCIe954 UARTs mem
0xd5efc000-0xd5ef,0xd5c0-0xd5df,0xd5a0-0xd5bf irq 18
at device 0.0 on pci8
puc0: 4 UARTs detected
puc0: [FILTER]
uart2: 16950 or compatible on puc0
uart2: [FILTER]
uart3: 16950 or compatible on puc0
uart3: [FILTER]
uart4: 16950 or compatible on puc0
uart4: [FILTER]
uart5: 16950 or compatible on puc0
uart5: [FILTER]
puc0@pci0:4:0:0:class=0x070002 card=0xc1581415 chip=0xc1581415
rev=0x00 hdr=0x00
vendor = 'Oxford Semiconductor Ltd'
class = simple comms
subclass = UART
bar [10] = type Memory, range 32, base 0xf9dfc000, size 16384, enabled
bar [14] = type Memory, range 32, base 0xfa00, size 2097152, enabled
bar [18] = type Memory, range 32, base 0xf9e0, size 2097152, enabled
That is correct.
The kernel is actually FreeBSD 9.0-BETA1 amd64, which is not quite
'STABLE' yet, but I don't think that this should matter.
Any advice would be much appreciated. The machine is still in
test phase, so I can mess around with it as necessary.
Hopefully this gets your Startech board working. I look forward to your
feedback.
If all else fails, the board I'm using is Lindy 51189. It's a OXPCIe954
board, offering four ports via a breakout cable, and is normally pretty
cheap direct from lindy.com (quite possibly cheaper than your two port
Startech board!). However, this recommendation comes with the proviso
that I haven't yet tried it with FreeBSD 9.x.
With best wishes,
David
--
David Wood
da...@wood2.org.uk
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman
Re: reboot sometimes freezes, adaptic scsi card possible problem
Hi Burt, In message [EMAIL PROTECTED], burt rosenberg [EMAIL PROTECTED] writes On reboot, one out of 10 times, reboot (from hardware initialization) stops. This is about a Dell PowerEdge 2950. I'd start by upgrading the BIOS - and whilst you're at it, I'd bring the whole machine up to date, as the BMC firmware, backplane firmware and PERC firmware are all likely to be out of date as well. The Dell System Build and Update Utility CD with the Server Updates DVD will handle all the necessary updates. The ISOs are available on the Dell Downloads site. The current System Build and Update Utility CD is rather old - I'd use the System Management Tools and Documentation DVD in its place (which boots into the System Build and Update Utility). You boot the System Build and Update Utility CD (or System Management Tools and Documentation DVD), tell the machine that the repository is on a DVD, and it will prompt you to change disk. Insert the Server Updates DVD. You will need console access - keyboard, mouse and monitor. I think I noticed a USB KVM somewhere amongst the information you gave. You don't have a DRAC 5 in the machine - if you did, you could have used the DRAC console. This system handles the correct sequencing of the upgrades (for example, you should upgrade the BMC firmware before the BIOS - at least, I believe that's the correct order, but I'd have to check) and carries out the upgrades in an environment where your hard disks aren't mounted. You may even find you have hard disk firmware updates outstanding. The BIOS in the machine is old - version 1.2.0. The next revision, 1.3.7, which is far from the latest, has something that sounds possibly relevant: Fixed possible issue of system device re-enumeration after power failures. There are also potential updates for your processor microcode and memory reference code just by updating the BIOS. Obviously, upgrading all the firmware in your machine is a potentially dangerous operation. My experience is that all will go well, but I can't guarantee that you won't hit trouble. Best wishes, David -- David Wood [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Dell Perc 6 disk geometry problem with RAID5 (both 6.3 final and 7.0 RC1)
[ambrisko@ and scottl@ added to CCs] Hi there, In message [EMAIL PROTECTED], Aldas Nabazas [EMAIL PROTECTED] writes We bought a new Dell PowerEdge 2950III with Perc 6/i and have the disk geometry problem using 6.3 final or 7.0 RC1. Seems that we are not alone at least one guy has similar problem reported earlier: http://unix.derkeiler.com/Mailing-Lists/FreeBSD/questions/2008-01/msg00506.html I was reading the mailing list and found that some of the people are happily using this hardware with the latest FreeBSD: http://lists.freebsd.org/pipermail/freebsd-stable/2008-January/039675.html I just wonder what the status of mfi driver? Maybe it's not fully tested or there will be some important fixes before 7.0 final? We are going to try different RAID combinations but it definitely not working using 6x146GB as RAID5. This is extremely disappointing to read, as I was relatively close to buying a Poweredge 2950 III with PERC 6/i. However, it's no good to me if mfi(4) has issues with large virtual disks; the tentative disk configuration is 2x146GB as RAID 1 and 4x750GB (or 1TB) as RAID 5. Looking at CVSweb: http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/mfi/ the updates for the 1078 chip which powers the PERC 6 series were contributed by LSI, so you would have hoped things were right. There is a disclaimer on the code, but you would also hope that someone in the know is testing it, especially as my impression has always been that the FreeBSD community is favourably disposed towards LSI storage controllers and that LSI and their vendors try to help the FreeBSD developers. Maybe someone could share the RAID combinations they successfully are running on? I haven't been keeping a very close eye on the problem as I don't currently have any hardware - but is the issue simply one of virtual disk size - there's a cut-off size after which things don't work properly? You could try pulling disks from your server (or removing them from the virtual disk) one by one until things start to work. To save a lot of pain you could create a virtual disk containing one disk as RAID 0 (a single disk) and install the OS on it, leaving the other five disks to play with. I do hope that someone is in a position to investigate this quickly - even if it's too late to get the fix in 7.0-RELEASE now. There's nothing that I can see as relevant that's waiting for MFC, anyway. Of course, it's worth checking whether you've got the latest firmware on the PERC 6/i - the latest version from Dell appears to be 6.0.1-0080. If this doesn't get fixed soon, I'm either going to have to go to another hardware vendor that uses a different RAID controller (HP is a possibility - though we're an all Dell shop) or - sniff - leave FreeBSD in favour of a Linux distribution. I realise that FreeBSD is a volunteer project, and that users can't have any specific expectations - this is not a threat, as I like FreeBSD and want to remain in the community, but I would need a new server to work properly! Looking at CVSweb, it seems that ambrisko@ and scottl@ are the two people most closely associated with the mfi code - I've added them into the CCs. My apologies if that was unwelcome. Best wishes, David -- David Wood [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Dell Perc 6 disk geometry problem with RAID5 (both 6.3 final and 7.0 RC1)
Hi there, In message [EMAIL PROTECTED], Erik Trulsson [EMAIL PROTECTED] writes On Sun, Jan 20, 2008 at 04:48:56PM +, David Wood wrote: In message [EMAIL PROTECTED], Aldas Nabazas [EMAIL PROTECTED] writes We bought a new Dell PowerEdge 2950III with Perc 6/i and have the disk geometry problem using 6.3 final or 7.0 RC1. Seems that we are not alone at least one guy has similar problem reported earlier: http://unix.derkeiler.com/Mailing-Lists/FreeBSD/questions/2008-01/msg0 0506.html I do not know if the mfi(4) driver has any problems with large disks, but it is however well known that fdisk(8) and bsdlabel(8) (the tools normally used to partition disks) have problems with volumes larger than 2TB. If you want to use volumes larger than 2TB then gpt(8) is the recommended way to partition the disks. It is however doubtful if the BIOS in your system will allow you to boot from a gpt(8) parttioned volume which is best solved with having a separate - smaller - boot volume where the OS itself is installed. Erik's reminder is timely for those with 2TB volumes. You must use gpt and not fdisk on any disk, be it a single drive (in the future, at least!) or a virtual disk on a RAID setup that are bigger than 2TB. It may be wise to use gpt on any virtual disk that you might grow to 2TB or larger in the future, so long as you're not needing to boot from that virtual disk. fdisk will not work properly with 2TB and larger volumes - the MBR / partition table setup can't cope with these large volumes. You can't boot from a GPT volume - that's a limitation of the BIOS architecture. There is some thought about using EFI on x64 hardware in the future (EFI is used on ia64 hardware; GPT is part of EFI), but we're not there yet. This isn't just about adding GPT support to the BIOS - the whole BIOS setup is wedded to MBR. If you need to boot from a 2TB array, create two virtual disks - one smaller than 2TB to boot from (and use MBR on that), then the residue can be GPT. However, Erik's 6*146 is only 846GB, which should be fine as an MBR / partition table volume (and the use of RAID 5 means you only have 5*146 usable in any case). The referenced problem on freebsd-questions sounds like a failure to use GPT, but Erik's problem sounds different. When I said there was nothing relevant waiting for MFC, I was aware of the change that Tom mentioned, but that seems to be about Dell PERC 6 being identified as such rather than a MegaRAID. It doesn't seem that it will change the behaviour of the driver in any way. There's another change in -CURRENT to do with the log buffer; again, that doesn't seem to be relevant here. Nevertheless, if one or both of these changes are felt stable enough to be MFCed to RELENG_7 and ideally RELENG_7_0, that would be good. I do have my doubts as to whether agreement will be got to merge them to RELENG_7_0 at this stage, however. Erik - can you post dmesg output, details on how you've arranged the physical disks into virtual disks, exactly how you get an anomalous result, and why you think what you're seeing is wrong. I went to look at HP, and I wasn't particularly happy with their offering. The Proliant DL380 G5 isn't a bad machine - but it uses 2.5 inch disks, and I prefer the 6 x 3.5 inch option available with the Dell Poweredge 2950. With the current state of development of disks and my requirement for a high capacity array, a 3.5 inch based machine is more suited to my needs. I also prefer the way that you order a Dell. I do hope we can reassure ourselves over the PERC 6/i. The PERC 5 series seems to have an excellent reputation under FreeBSD, and hopefully the newer PERC 6 series will soon get the same excellent reputation. Best wishes, David -- David Wood [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: RELENG_7, RELENG_7_0, RELENG_7_BP, RELENG_7_0_BP - difference?
Hi Jakub, In message [EMAIL PROTECTED], Jakub Siroky [EMAIL PROTECTED] writes I should probably know that, but: what's the difference between these branches? RELENG_7 is 7-STABLE. RELENG_7_0 will become 7.0-RELEASE, and is what you should track now if you intend to upgrade to 7.0-RELEASE. After 7.0-RELEASE, it will be turned over to the security team, and only security fixes and errata will be checked in (7.0-RELEASE-p1 etc.). The _BP versions mark the branch points - where the tree was when the tag mentioned was branched. They won't be updated at all. Corrections are welcomed if I've misunderstood. Best wishes, David -- David Wood [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: SOLVED: qemu: freebsd6_mmap -1 errno 12 Cannot allocate memory
with Harpertown processors (the new Penryn based E54xx Xeons). You may well have different priorities to mine in terms of what you upgrade to and when - but I believe that you should consider the security implications of your actions. Best wishes, David -- David Wood [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
