installer freebsd9 bata1
Welcome I installed freebsd 9bata1 and noticed the installer does not create a user account's home directory. Have to manually create after installation. Greet ___ 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: installer freebsd9 beta1
Hello *, I'll just add a 'me too'. Had not posted to the list because I wasn't sure if it wasn't because of me :-) Best regards, Holger Am 22.08.2011 um 09:26 schrieb Yampress: > Welcome > I installed freebsd 9bata1 and noticed the installer does not create a user > account's home directory. > Have to manually create after installation. > Greet > ___ > 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" -- Holger Kipp Diplom-Mathematiker Senior Consultant Tel. : +49 30 436 58 114 Fax. : +49 30 436 58 214 Mobil: +49 178 36 58 114 Email: holger.k...@alogis.com alogis AG Alt-Moabit 90b D-10559 Berlin web : http://www.alogis.com -- alogis AG Sitz/Registergericht: Berlin/AG Charlottenburg, HRB 71484 Vorstand: Arne Friedrichs, Joern Samuelson Aufsichtsratsvorsitzender: Reinhard Mielke ___ 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
On Mon, Aug 22, 2011 at 12:20:33AM +0200, Greg Byshenk wrote:
> On Sun, Aug 21, 2011 at 09:44:41PM +0100, David Wood wrote:
>
> > I wrote and contributed the support code for the OXPCIe95x serial chips
> > - and just happened to notice your report.
>
> Thanks for the response.
>
>
> > In message <20110821154249.ge92...@core.byshenk.net>, Greg Byshenk
> > 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"?
>
> I will rebuild my kernel and try.
>
>
> > >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
>
> Interestingly, it -is- a no-op on the device, which I hadn't noticed.
> But trying to set it on the .init fails:
>
> # stty -f /dev/cuau2.init speed 115200
> stty: /dev/cuau2.init isn't a terminal 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: 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: 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: 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
>
>
> > >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]
Re: Serial multiport error Oxford/Startech PEX2S952
Hi Greg,
In message <20110822083336.gi92...@core.byshenk.net>, Greg Byshenk
writes
On Mon, Aug 22, 2011 at 12:20:33AM +0200, Greg Byshenk wrote:
puc0: 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
On Mon, Aug 22, 2011 at 10:23:14AM +0100, David Wood wrote:
> In message <20110822083336.gi92...@core.byshenk.net>, Greg Byshenk
> writes
> >On Mon, Aug 22, 2011 at 12:20:33AM +0200, Greg Byshenk wrote:
> >>puc0: 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.
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.
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.
I'll followup again when I have something to report.
--
greg byshenk - gbysh
Re: Serial multiport error Oxford/Startech PEX2S952
Dear Greg, In message <20110822094756.gj92...@core.byshenk.net>, Greg Byshenk 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: WD Advanced Format: do I need to do something special?
On 18/08/2011 11:55, Yuri wrote: On 08/18/2011 02:17, Jeremy Chadwick wrote: The below advice still applies. Do not skim the page, read it. http://ivoras.net/blog/tree/2011-01-01.freebsd-on-4k-sector-drives.html You will therefore have to go through some manual rigmarole (preferably with gpart(8)) to ensure performance. If you plan on using the disks in ZFS, you get to go through some extra rigmarole. I didn't know about such extra actions that are required and just created ZFS pool. zdb -C shows ashift as 9. I read it as meaning that sector size if 512bytes (wrong!). But I tested the 25GB file writing/reading speed on the middle tracks and it seems reasonable: WR 55MB/s RD 107MB/s So can I get even better speeds if it was aware of 4k sector? Yes, read and write speeds on modern drives should be almost equal. ___ 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: WD Advanced Format: do I need to do something special?
On 19/08/2011 03:28, Yuri wrote: Following instructions here (http://ivoras.net/blog/tree/2011-01-01.freebsd-on-4k-sector-drives.html) I destroyed my previous ZFS pool with 512 byte sectors and did this: gnop create -S 4096 /dev/ad4 zpool create mypool /dev/ad4.nop zpol create mypool/mydir zpool export mypool gnop destroy /dev/ad4.nop zpool import mypool Now this command 'zdb -C data | grep ashift' shows ashift=12 (4096 byte sectors). However, when I begin to copy a lot of files files into /mypool/mydir online radio player gets severely affected. Sound get interrupted all the time. Itrettuptions stop after 1-2 secs after I stop copying. This didn't happen with sector size 512 bytes. What is wrong? Which version of FreeBSD are you doing this on? Do you have any non-default tuning? ___ 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: 32GB limit per swap device?
On 2011-Aug-18 12:16:44 +0400, "Alexander V. Chernikov" wrote: >The code should look like this: ... >(move pages recalculation before b-list check) I notice a very similar patch has been applied to -current as r225076. For the archives, I've done some testing with this patch on a Sun V890 with 64GB RAM and two 64GB swap partitions. Prior to this patch, each swap partition was truncated to 32GB. With this patch, I have 128GB swap. I've tried filling the swap space to over 80GB and I am not seeing any corruption (allocate lots of memory and fill with a known pseudo-random pattern and then verify). -- Peter Jeremy pgpo8PkzVBfqo.pgp Description: PGP signature
Re: 32GB limit per swap device?
The limitation was ONLY due to a *minor* 32-bit integer overflow in one or two *intermediate* calculations in the radix tree code, which I long ago fixed in DragonFly. Just find the changes in the DFly codebase and determine if they need to be applied. The swap space radix code (which I wrote long ago) is in page-sized blocks, so you actually probably want to keep using a 32-bit integer for the block number there to keep the physical memory reservation required for the radix tree low. If you just pop the base block id up to 64 bits without adjusting the radix code to overlay a 64 bit bitmap on it you waste a lot of physical memory for the same amount of swap reservation. This is NOT where the limitation lies. It was strictly an intermediate calculation that caused the original limitation. With 32 bit block numbers stored in the radix tree nodes in the swap code the physical limitation is something like 1 to 4 TB of total swap. I forget exactly but it is at least 1TB. I've tested 1TB swap partitions on DragonFly with just the minor fixes to the original radix tree code. -- Also note that I believe FreeBSD has done away with the interleaved swap. I'm not sure why, I guess geom can interleave the swap for you but I've always thought that it would be easier to just specify and add the partitions separately so one has the flexibility to swapon and swapoff the individual partitions on a live system. Interleaving is important because you get an almost perfect performance multiplier. You don't want to just append the swap partitions after each other. -- One last thing: The amount of wired physical memory required is still on the order of ~1MB per ~1GB of swap. A 32-bit kernel is thus still limited by available KVM, effectively limiting you to around ~32G of swap depending on various factors if you do not want to run the system out of KVM. I've run upwards of 128G of swap on 32-bit systems but it really pushed the KVM use and I would not recommend it. A 64-bit kernel is *NOT* limited by KVM. Swap is effectively limited to ~1TB or ~2TB using the original radix code with the one or two intermediate overflow fixes applied. The daddr_t in the original radix code can remain 32-bits (in DragonFly I typedef'd another name so I could explicitly make it 32-bits regardless of daddr_t). Large amounts of swap space are becoming important as things like tmpfs (and swapcache in DragonFly as well) can really make use of it. Swap performance (the ability to interleave the swap space) is also important for the same reason. Interleaved swap on two SATA-III SSDs is just insane... gives you something like 800MB/sec of aggregate read bandwidth. -Matt ___ 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"
