Re: bad sector in gmirror HDD
On 2011-Aug-19 20:24:38 -0700, Jeremy Chadwick free...@jdc.parodius.com wrote: The reallocated LBA cannot be dealt with aside from re-creating the filesystem and telling it not to use the LBA. I see no flags in newfs(8) that indicate a way to specify LBAs to avoid. And we don't know what LBA it is so we can't refer to it right now anyway. As I said previously, I have no idea how UFS/FFS deals with this. It doesn't. UFS/FFS and ZFS expect and assume perfect media. It's up to the drive to transparently remap faulty sectors. UFS used to have support for visible bad sectors (and Solaris UFS still reserves space for this, though I don't know if it still works) but the code was removed from FreeBSD long ago. AFAIR, wd(4) supported bad sectors but it was removed long ago. -- Peter Jeremy pgpzqxeB9mDZP.pgp Description: PGP signature
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
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?
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: 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: 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
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,
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
On Mon, Aug 22, 2011 at 10:23:14AM +0100, David Wood wrote:
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.
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...@byshenk.net - Leiden, NL
___
freebsd-stable@freebsd.org mailing list
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: 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 mypool 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 melif...@ipfw.ru 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
