newfs broken in -CURRENT after 204654
On Thu, Mar 04, 2010 at 06:34:03PM +0530, C. Jayachandran wrote:
I'm testing this on the mips platform, but I think there is an issue
with change that made sectorsize int64_t, because the ioctl
DIOCGSECTORSIZE used to read sector size seems to take u_int. This
quick change fixes it for me (sample patch - may be whitespace
damaged).
I'm trying this one more time, since the issue is still unresolved.
newfs(8) broke for big-endian systems since revision 204654. This change
made sectorsize variable int64_t, and now it cannot be passed to the ioctl
DIOCGSECTORSIZE.
The patch below (updated from the previous one) fixes it, please review and
apply if correct.
Thanks,
JC.
Index: sbin/newfs/newfs.c
===
--- sbin/newfs/newfs.c (revision 204701)
+++ sbin/newfs/newfs.c (working copy)
@@ -132,6 +132,7 @@
char *cp, *special;
intmax_t reserved;
int ch, i, rval;
+ u_int tsecsize;
off_t mediasize;
char part_name; /* partition name, default to full disk */
@@ -327,9 +328,12 @@
mediasize = st.st_size;
/* set fssize from the partition */
} else {
- if (sectorsize == 0)
- if (ioctl(disk.d_fd, DIOCGSECTORSIZE, sectorsize) == -1)
+ if (sectorsize == 0) {
+ if (ioctl(disk.d_fd, DIOCGSECTORSIZE, tsecsize) == -1)
sectorsize = 0; /* back out on error for safety */
+ else
+ sectorsize = tsecsize;
+ }
if (sectorsize ioctl(disk.d_fd, DIOCGMEDIASIZE, mediasize) !=
-1)
getfssize(fssize, special, mediasize / sectorsize, reserved);
}
___
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
A tool for remapping bad sectors in CURRENT?
Hello, all! Recently I've started to see the following logs in messages: Mar 8 12:00:24 localhost smartd[795]: Device: /dev/ad4, 2 Currently unreadable (pending) sectors Mar 8 12:00:24 localhost smartd[795]: Device: /dev/ad4, 2 Offline uncorrectable sectors smartctl did really show that something is wrong with my HDD, but still no remaps - just read errors. SMART Self-test log structure revision number 1 Num Test_DescriptionStatus Remaining LifeTime(hours) LBA_of_first_error # 1 Extended offlineCompleted: read failure 60% 1198 222342559 # 2 Extended offlineCompleted: read failure 60% 1187 222342557 # 3 Extended offlineCompleted: read failure 60% 1180 222342559 # 4 Short offline Completed without error 00% 1178 - # 5 Extended offlineAborted by host 90% 1178 - and ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE ... Reallocated_Sector_Ct 0x0033 100 100 036Pre-fail Always - 0 ... Now can I find out which file owns the LBAs 222342557 and 222342559 ? How do I force remapping of these sectors? I assume that I have to write something directly to the sectors? Thank you all in advance! -- Eugene N Dzhurinsky pgpqQ6jlbF1Sg.pgp Description: PGP signature
Re: A tool for remapping bad sectors in CURRENT?
Eugeny N Dzhurinsky wrote: Recently I've started to see the following logs in messages: Mar 8 12:00:24 localhost smartd[795]: Device: /dev/ad4, 2 Currently unreadable (pending) sectors Mar 8 12:00:24 localhost smartd[795]: Device: /dev/ad4, 2 Offline uncorrectable sectors smartctl did really show that something is wrong with my HDD, but still no remaps - just read errors. SMART Self-test log structure revision number 1 Num Test_DescriptionStatus Remaining LifeTime(hours) LBA_of_first_error # 1 Extended offlineCompleted: read failure 60% 1198 222342559 # 2 Extended offlineCompleted: read failure 60% 1187 222342557 # 3 Extended offlineCompleted: read failure 60% 1180 222342559 # 4 Short offline Completed without error 00% 1178 - # 5 Extended offlineAborted by host 90% 1178 - and ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE ... Reallocated_Sector_Ct 0x0033 100 100 036Pre-fail Always - 0 ... Now can I find out which file owns the LBAs 222342557 and 222342559 ? How do I force remapping of these sectors? I assume that I have to write something directly to the sectors? You may try to overwrite these sectors with dd. It should trigger sector reallocation. To be sure, you may read them before and after the write. -- 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: A tool for remapping bad sectors in CURRENT?
In message 20100308102918.ga5...@localhost, Eugeny N Dzhurinsky writes: Now can I find out which file owns the LBAs 222342557 and 222342559 ? How do I force remapping of these sectors? I assume that I have to write something directly to the sectors? I would suggest you boot single-user and run mdmfs -s 1m md /tmp recoverdisk -w /tmp/_.wl /dev/ad4 /dev/ad4 That will find out how many bad sectors you have and try to recover the contents of them if possible, leave it running as long as you care for. If you interrupt it, the /tmp/_.wl file will contain a list of areas not yet successfully read/written. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ 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: A tool for remapping bad sectors in CURRENT?
On Mon, Mar 08, 2010 at 12:31:24PM +0200, Alexander Motin wrote: You may try to overwrite these sectors with dd. It should trigger sector reallocation. To be sure, you may read them before and after the write. dd if=/dev/ad4 of=/dev/null skip=222342559 bs=512 count=1 dd: /dev/ad4: Input/output error 0+0 records in 0+0 records out 0 bytes transferred in 2.351940 secs (0 bytes/sec) dd if=/dev/zero of=/dev/ad4 seek=222342559 bs=512 count=1 dd: /dev/ad4: Operation not permitted Should I do it in single mode? -- Eugene N Dzhurinsky pgpMrducrommM.pgp Description: PGP signature
Re: A tool for remapping bad sectors in CURRENT?
On Mon, Mar 08, 2010 at 10:51:22AM +, Poul-Henning Kamp wrote: I would suggest you boot single-user and run mdmfs -s 1m md /tmp recoverdisk -w /tmp/_.wl /dev/ad4 /dev/ad4 That will find out how many bad sectors you have and try to recover the contents of them if possible, leave it running as long as you care for. If you interrupt it, the /tmp/_.wl file will contain a list of areas not yet successfully read/written. Well, I just want to force IDE drive to remap things :) -- Eugene N Dzhurinsky pgp0a7Gsgnv97.pgp Description: PGP signature
Re: A tool for remapping bad sectors in CURRENT?
On Mon, Mar 08, 2010 at 12:52:43PM +0200, Eugene Dzhurinsky wrote: dd if=/dev/ad4 of=/dev/null skip=222342559 bs=512 count=1 dd: /dev/ad4: Input/output error 0+0 records in 0+0 records out 0 bytes transferred in 2.351940 secs (0 bytes/sec) dd if=/dev/zero of=/dev/ad4 seek=222342559 bs=512 count=1 dd: /dev/ad4: Operation not permitted Should I do it in single mode? sysctl kern.geom.debugflags=0x10 Did the trick, I was able to write directly to the sector, and now it seems to work well. No remaps recorded thus, but no errors so far. Thanks a lot! -- Eugene N Dzhurinsky pgpbcuR5aO8BX.pgp Description: PGP signature
Re: A tool for remapping bad sectors in CURRENT?
Eugeny N Dzhurinsky wrote: Hello, all! Recently I've started to see the following logs in messages: Mar 8 12:00:24 localhost smartd[795]: Device: /dev/ad4, 2 Currently unreadable (pending) sectors Mar 8 12:00:24 localhost smartd[795]: Device: /dev/ad4, 2 Offline uncorrectable sectors smartctl did really show that something is wrong with my HDD, but still no remaps - just read errors. SMART Self-test log structure revision number 1 Num Test_DescriptionStatus Remaining LifeTime(hours) LBA_of_first_error # 1 Extended offlineCompleted: read failure 60% 1198 222342559 # 2 Extended offlineCompleted: read failure 60% 1187 222342557 # 3 Extended offlineCompleted: read failure 60% 1180 222342559 # 4 Short offline Completed without error 00% 1178 - # 5 Extended offlineAborted by host 90% 1178 - and ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE ... Reallocated_Sector_Ct 0x0033 100 100 036Pre-fail Always - 0 ... Now can I find out which file owns the LBAs 222342557 and 222342559 ? How do I force remapping of these sectors? I assume that I have to write something directly to the sectors? We have this problem from time to time on bunch of machines. As we are using gmirror, the easiest way is to force re-synchronization (rewrite) of the whole drive. The problem is when there are Pending unreadable sectors on both drives - it ends up with read error and some file(s) are corrupted, but there is no easy way (on FreeBSD) to find what file. I tried it in the past with fsdb / findblk, but it does not work as I expect or I do not fully understand the needed calculations with slices + partitions offsets / LBAs and right meaning of the term block. It seems there are several meaning in different contexts. It would be nice if somebody with enough FS / GEOM knowledge can write some HowTo or shell script to do the calculations and operations to find file containing bad sector(s) and put it in FAQ, Handbook, or Wiki. Miroslav Lachman ___ 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: A tool for remapping bad sectors in CURRENT?
On Mon, 8 Mar 2010, Miroslav Lachman wrote: Eugeny N Dzhurinsky wrote: Hello, all! Recently I've started to see the following logs in messages: Mar 8 12:00:24 localhost smartd[795]: Device: /dev/ad4, 2 Currently unreadable (pending) sectors Mar 8 12:00:24 localhost smartd[795]: Device: /dev/ad4, 2 Offline uncorrectable sectors smartctl did really show that something is wrong with my HDD, but still no remaps - just read errors. SMART Self-test log structure revision number 1 Num Test_DescriptionStatus Remaining LifeTime(hours) LBA_of_first_error # 1 Extended offlineCompleted: read failure 60% 1198 222342559 # 2 Extended offlineCompleted: read failure 60% 1187 222342557 # 3 Extended offlineCompleted: read failure 60% 1180 222342559 # 4 Short offline Completed without error 00% 1178 - # 5 Extended offlineAborted by host 90% 1178 - and ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE ... Reallocated_Sector_Ct 0x0033 100 100 036Pre-fail Always - 0 ... Now can I find out which file owns the LBAs 222342557 and 222342559 ? How do I force remapping of these sectors? I assume that I have to write something directly to the sectors? We have this problem from time to time on bunch of machines. As we are using gmirror, the easiest way is to force re-synchronization (rewrite) of the whole drive. The problem is when there are Pending unreadable sectors on both drives - it ends up with read error and some file(s) are corrupted, but there is no easy way (on FreeBSD) to find what file. *cough* zfs *cough* I believe this kind of silent corruption is precisely what zfs was designed to prevent. Even though you do have a mirror, how do you know which copy is the correct one? If one drive re-allocates the sector silently, what is the recovery method? If gmirror synchronizes, how do you make sure that the *good* copy is the one synchronized? You'll notice it eventually if you see it in a garbled file, but how does the filesystem handle it? I tried it in the past with fsdb / findblk, but it does not work as I expect or I do not fully understand the needed calculations with slices + partitions offsets / LBAs and right meaning of the term block. It seems there are several meaning in different contexts. It would be nice if somebody with enough FS / GEOM knowledge can write some HowTo or shell script to do the calculations and operations to find file containing bad sector(s) and put it in FAQ, Handbook, or Wiki. ___ 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: A tool for remapping bad sectors in CURRENT?
On Mon, Mar 08, 2010 at 12:21:44PM +0100, Miroslav Lachman wrote: Eugeny N Dzhurinsky wrote: We have this problem from time to time on bunch of machines. As we are using gmirror, the easiest way is to force re-synchronization (rewrite) of the whole drive. The problem is when there are Pending unreadable sectors on both drives - it ends up with read error and some file(s) are corrupted, but there is no easy way (on FreeBSD) to find what file. I tried it in the past with fsdb / findblk, but it does not work as I expect or I do not fully understand the needed calculations with slices + partitions offsets / LBAs and right meaning of the term block. It seems there are several meaning in different contexts. It would be nice if somebody with enough FS / GEOM knowledge can write some HowTo or shell script to do the calculations and operations to find file containing bad sector(s) and put it in FAQ, Handbook, or Wiki. Miroslav, thank you for the suggestion - but I am not using gmirror, that HDD is the one on my laptop. However suggestions about using dd to write something into bad block to force IDE controller do it's service stuff about remapping seems did the trick. And I was able to not calculate LBA but use it as block offset, which seemed to be correct way :) -- Eugene N Dzhurinsky pgpRqAzvt8cSz.pgp Description: PGP signature
Re: newfs broken in -CURRENT after 204654
On Mon, 8 Mar 2010 14:17:17 +0530
Jayachandran C. c.jayachand...@gmail.com wrote:
On Thu, Mar 04, 2010 at 06:34:03PM +0530, C. Jayachandran wrote:
I'm testing this on the mips platform, but I think there is an issue
with change that made sectorsize int64_t, because the ioctl
DIOCGSECTORSIZE used to read sector size seems to take u_int. This
quick change fixes it for me (sample patch - may be whitespace
damaged).
I'm trying this one more time, since the issue is still unresolved.
newfs(8) broke for big-endian systems since revision 204654. This change
made sectorsize variable int64_t, and now it cannot be passed to the ioctl
DIOCGSECTORSIZE.
The patch below (updated from the previous one) fixes it, please review and
apply if correct.
Thanks,
JC.
Index: sbin/newfs/newfs.c
===
--- sbin/newfs/newfs.c(revision 204701)
+++ sbin/newfs/newfs.c(working copy)
@@ -132,6 +132,7 @@
char *cp, *special;
intmax_t reserved;
int ch, i, rval;
+ u_int tsecsize;
off_t mediasize;
char part_name; /* partition name, default to full disk */
@@ -327,9 +328,12 @@
mediasize = st.st_size;
/* set fssize from the partition */
} else {
- if (sectorsize == 0)
- if (ioctl(disk.d_fd, DIOCGSECTORSIZE, sectorsize) == -1)
+ if (sectorsize == 0) {
+ if (ioctl(disk.d_fd, DIOCGSECTORSIZE, tsecsize) == -1)
sectorsize = 0; /* back out on error for safety */
+ else
+ sectorsize = tsecsize;
+ }
if (sectorsize ioctl(disk.d_fd, DIOCGMEDIASIZE, mediasize) !=
-1)
getfssize(fssize, special, mediasize / sectorsize, reserved);
}
I can't say whether this is correct, but the logic could definitely be
simplified like this, since sectorsize is known to be 0 already:
if (sectorsize == 0)
if (ioctl(disk.d_fd, DIOCGSECTORSIZE, tsecsize) = 0)
sectorsize = tsecsize;
---
Gary Jennejohn
___
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: newfs broken in -CURRENT after 204654
In message 20100308125643.1ac0b...@ernst.jennejohn.org, Gary Jennejohn writes
:
On Mon, 8 Mar 2010 14:17:17 +0530
I'm trying this one more time, since the issue is still unresolved.
newfs(8) broke for big-endian systems since revision 204654. This change
made sectorsize variable int64_t, and now it cannot be passed to the ioctl
DIOCGSECTORSIZE.
This patch is correct, DIOCGSECTORSIZE takes an unsigned argument, see
sys/disk.h:
#define DIOCGSECTORSIZE _IOR('d', 128, u_int)
/*-
* Get the sectorsize of the device in bytes. The sectorsize is the
* smallest unit of data which can be transfered from this device.
* Usually this is a power of two but it may not be. (ie: CDROM audio)
*/
I can't say whether this is correct, but the logic could definitely be
simplified like this, since sectorsize is known to be 0 already:
if (sectorsize == 0)
if (ioctl(disk.d_fd, DIOCGSECTORSIZE, tsecsize) = 0)
sectorsize = tsecsize;
I'm not sure that is a valid assumption.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
___
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: propose: all arch move into a separate dir
In article 20100307.144736.420173476735197890@bsdimp.com, Warner Losh i...@bsdimp.com writes: We don't have quite as many problems as the NetBSD/OpenBSD crowd in this respect. They tend to define a new MACHIINE more often then we have (or will). The need for sys/arch is less severe here than there because we don't have 40 different MACHINEs. Even if we did, I cannot think of any compelling reason to make such a change (and I don't recall one ever being brought up in our entire history). If we had forty architecture directories in /sys, so what? Why should it matter to anyone? If we were talking about 100 architectures, I might feel differently, but in this universe, we have, what? eight? And there are how many architectures currently in mass production? This whole discussion is ridiculous. -GAWollman ___ 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: propose: all arch move into a separate dir
In message 201003080329.o283tqic011...@hergotha.csail.mit.edu, Garrett Wollma n writes: If we were talking about 100 architectures, I might feel differently, but in this universe, we have, what? eight? And there are how many architectures currently in mass production? This whole discussion is ridiculous. Actually, that conclusion is probably premature. The System-On-Chip concept is boiling over these days, and everybody and his brother are designing CPUs for themselves. 100 is unlikely, but 8 may be 20 in two years time, depending on the way the wind blows. Poul-Henning -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ 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: newfs broken in -CURRENT after 204654
On Mon, 08 Mar 2010 11:58:39 +
Poul-Henning Kamp p...@phk.freebsd.dk wrote:
In message 20100308125643.1ac0b...@ernst.jennejohn.org, Gary Jennejohn
writes
:
On Mon, 8 Mar 2010 14:17:17 +0530
I'm trying this one more time, since the issue is still unresolved.
newfs(8) broke for big-endian systems since revision 204654. This change
made sectorsize variable int64_t, and now it cannot be passed to the ioctl
DIOCGSECTORSIZE.
This patch is correct, DIOCGSECTORSIZE takes an unsigned argument, see
sys/disk.h:
#define DIOCGSECTORSIZE _IOR('d', 128, u_int)
/*-
* Get the sectorsize of the device in bytes. The sectorsize is the
* smallest unit of data which can be transfered from this device.
* Usually this is a power of two but it may not be. (ie: CDROM audio)
*/
I can't say whether this is correct, but the logic could definitely be
simplified like this, since sectorsize is known to be 0 already:
if (sectorsize == 0)
if (ioctl(disk.d_fd, DIOCGSECTORSIZE, tsecsize) = 0)
sectorsize = tsecsize;
I'm not sure that is a valid assumption.
I disagree, but there's no reason to get into a bike-shed painting contest :)
The
original patch is OK the way it is.
---
Gary Jennejohn
___
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: newfs broken in -CURRENT after 204654
On Mon, Mar 08, 2010 at 11:58:39AM +, Poul-Henning Kamp wrote:
In message 20100308125643.1ac0b...@ernst.jennejohn.org, Gary Jennejohn
writes
:
On Mon, 8 Mar 2010 14:17:17 +0530
I'm trying this one more time, since the issue is still unresolved.
newfs(8) broke for big-endian systems since revision 204654. This change
made sectorsize variable int64_t, and now it cannot be passed to the ioctl
DIOCGSECTORSIZE.
This patch is correct, DIOCGSECTORSIZE takes an unsigned argument, see
sys/disk.h:
#define DIOCGSECTORSIZE _IOR('d', 128, u_int)
/*-
* Get the sectorsize of the device in bytes. The sectorsize is the
* smallest unit of data which can be transfered from this device.
* Usually this is a power of two but it may not be. (ie: CDROM audio)
*/
I can't say whether this is correct, but the logic could definitely be
simplified like this, since sectorsize is known to be 0 already:
if (sectorsize == 0)
if (ioctl(disk.d_fd, DIOCGSECTORSIZE, tsecsize) = 0)
sectorsize = tsecsize;
I'm not sure that is a valid assumption.
I think I missed this one. Probably we could do ioctl(...) != -1 and be
equivalent.
Thanks for the comments. New patch below.
Index: sbin/newfs/newfs.c
===
--- sbin/newfs/newfs.c (revision 204858)
+++ sbin/newfs/newfs.c (working copy)
@@ -132,6 +132,7 @@
char *cp, *special;
intmax_t reserved;
int ch, i, rval;
+ u_int tsecsize;
off_t mediasize;
char part_name; /* partition name, default to full disk */
@@ -328,8 +329,8 @@
/* set fssize from the partition */
} else {
if (sectorsize == 0)
- if (ioctl(disk.d_fd, DIOCGSECTORSIZE, sectorsize) == -1)
- sectorsize = 0; /* back out on error for safety */
+ if (ioctl(disk.d_fd, DIOCGSECTORSIZE, tsecsize) != -1)
+ sectorsize = tsecsize;
if (sectorsize ioctl(disk.d_fd, DIOCGMEDIASIZE, mediasize) !=
-1)
getfssize(fssize, special, mediasize / sectorsize, reserved);
}
Regards,
JC.
___
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: A tool for remapping bad sectors in CURRENT?
Eugene Dzhurinsky wrote: On Mon, Mar 08, 2010 at 12:21:44PM +0100, Miroslav Lachman wrote: Eugeny N Dzhurinsky wrote: We have this problem from time to time on bunch of machines. As we are using gmirror, the easiest way is to force re-synchronization (rewrite) of the whole drive. The problem is when there are Pending unreadable sectors on both drives - it ends up with read error and some file(s) are corrupted, but there is no easy way (on FreeBSD) to find what file. I tried it in the past with fsdb / findblk, but it does not work as I expect or I do not fully understand the needed calculations with slices + partitions offsets / LBAs and right meaning of the term block. It seems there are several meaning in different contexts. It would be nice if somebody with enough FS / GEOM knowledge can write some HowTo or shell script to do the calculations and operations to find file containing bad sector(s) and put it in FAQ, Handbook, or Wiki. Miroslav, thank you for the suggestion - but I am not using gmirror, that HDD is the one on my laptop. However suggestions about using dd to write something into bad block to force IDE controller do it's service stuff about remapping seems did the trick. And I was able to not calculate LBA but use it as block offset, which seemed to be correct way :) Yes, rewriting by dd or any other way works for reallocating or clearing pending sectors counter, but in server environment I need to know the affected file, as it can be for example database file and then it is a big problem! Rewriting the sector inside InnoDB ib_data file can cause DB crash, data loss etc. Miroslav Lachman ___ 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: Removing USB keyboard after filesystems synced causes panic with destroyed mutex twa(4)?
On Sun, Mar 7, 2010 at 11:24 AM, Garrett Cooper yanef...@gmail.com wrote: On Sun, Mar 7, 2010 at 2:07 AM, Garrett Cooper yanef...@gmail.com wrote: Hi Alexander and Hans, I recently did the following which generated a panic on a 9-CURRENT kernel compiled on the 26th: 1. Executed reboot 2. Removed keyboard. 3. Some time after `All buffers synced\nUptime: ...' was displayed, the keyboard was registered disconnected. 4. The interrupt was delivered to my twa(4) enabled card and the kernel panicked, like so: ugen2.2: Mitsumi Electric at usbus2 (disconnected) uhub8: at uhub2, port 1, addr 2 (disconnected) ugen2.3: Mitsumi Electric at usbus2 (disconnected) ukbd0: at uhub8, port 3, addr 3 (disconnected) uhid0: at uhub8, port 3, addr 3 (disconnected) panic: mtx_lock_spin() of destroyed mutex @ /usr/src/sys/dev/twa/tw_cl_intr.c:88 cpuid = 1 KDB: enter: panic [thread pid 12 tid 100025 ] Stopped at kdb_enter+0x3d: movq $0,0x40289c(%rip) db I wish I could provide you with more details, but unfortunately I the USB bus isn't registering the fact that I'm reattaching the keyboard right now and the box won't reboot automatically :( (didn't set the right sysctl beforehand to panic automatically). I'll try and reproduce the issue again, but I was just wondering whether or not you guys had seen this problem before. Phew... it's reproducible with that kernel. Here's what I did exactly (because my original directions were incorrect): 1. Hit power button (for S5). 2. Disconnect keyboard RIGHT as `Uptime: ...' is displayed. Kernel panicked on my system again. Now to figure out if it still exists with a kernel compiled today, and also how to debug it if it still does exist :/... I thinks that's a race in twa driver. You could unplug another USB device different from your keyboard and you should still got the panic. If you get the panic again try to show at least the following information: bt; show pcpu; show alllocks; show locks; ps Thank you -- Gianni ___ 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: dev.bce.X.com_no_buffers increasing and packet loss
Pyun YongHyeon wrote: On Fri, Mar 05, 2010 at 11:16:41PM +0200, Ian FREISLICH wrote: Pyun YongHyeon wrote: Thanks for the info. Frankly, I have no idea how to explain the issue given that you have no heavy load. How many cores would be involved in handling the traffic and runnig PF rules on this machine? There are 4x CPU: Quad-Core AMD Opteron(tm) Processor 8354 (2194.51-MHz K8-class CPU) In this server. I'm also using carp extensively. pf(4) uses a single lock for processing, number of core would have no much benefit. What's interesting is the effect on CPU utilisation and interrupt generation that net.inet.ip.fastforwarding has: net.inet.ip.fastforwarding=1 interrupt rate is around 1/s per bce interface cpu 8.0% interrupt net.inet.ip.fastforwarding=0 interrupt rate is around 5000/s per bce interface cpu 13.0% interrupt It also appears to not drop packets, but I'll have to watch it for longer. 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
Survey results very helpful, thanks! (was: Re: net.inet.tcp.timer_race: does anyone have a non-zero value?)
On Sun, 7 Mar 2010, Robert Watson wrote: If your system shows a non-zero value, please send me a *private e-mail* with the output of that command, plus also the output of sysctl kern.smp, uptime, and a brief description of the workload and network interface configuration. For example: it's a busy 8-core web server with roughly X connections/second, and that has three em network interfaces used to load balance from an upstream source. IPSEC is used for management purposes (but not bulk traffic), and there's a local MySQL database. I've now received a number of reports that confirm our suspicion that the race does occur, albeit very rarely, and particularly on systems with many cores or multiple network interfaces. Fixing it is definitely on the TODO for 9.0, both to improve our ability to do multiple virtual network stacks, but with an appropriately scalable fix in mind given our improved TCP scalability for 9.0 as well. Thanks for all the responses, Robert N M Watson Computer Laboratory University of Cambridge ___ 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: Wireless TCP aborts
Luigi Rizzo wrote: On Sun, Mar 07, 2010 at 03:08:38PM -0800, Chuck Swiger wrote: Hi, Tim-- On Mar 7, 2010, at 2:16 PM, Tim Kientzle wrote: [ ... ] Corrupted MAC on input. Disconnecting: Packet corrupt rsync: connection unexpectedly closed ... [receiver] and then the rsync session is dead. It's not TCP ... SSH adds it's own layer of data integrity checking ... long ago, with the 'iwi' driver, there was the following problem leading the the sae problem you are seeing: the driver was doing WEP in software, and wrote back the result to the original mbuf (actually, cluster). As a result, the first transmission of a segment was correct, but in case a rxmt, data would be encrypted twice, and the remote ssh end detected the garbage and dropped the connection. This was fixed with Sam's help around early 2007 if i remember well. An easy way to see if it is a similar problem is use ipfw to drop some packets e.g. ipfw add 100 prob 0.1 deny tcp out xmit wi0 // use your interface name I'll do some experimenting. Here are some more details on the current setup in case this rings any bells for anyone: * Sender: FreeBSD 8-CURRENT r193146, bge driver bge0: Broadcom NetXtreme Gigabit Ethernet Controller, ASIC rev. 0x6001 mem 0xe080-0xe080 irq 17 at device 0.0 on pci63 * Router: D-Link 655 * Receiver: FreeBSD 9-CURRENT r201154, ath driver ath0: Atheros 5424/2424 mem 0x5520-0x5520 irq 18 at device 0.0 on pci3 ath0: AR2425 mac 14.2 RF5424 phy 7.0 The wireless side is using WPA2-PSK. Tonight I'll try hooking up a wired connection to the receiver and see if that changes anything. 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: dev.bce.X.com_no_buffers increasing and packet loss
On Mon, Mar 08, 2010 at 04:45:20PM +0200, Ian FREISLICH wrote: Pyun YongHyeon wrote: On Fri, Mar 05, 2010 at 11:16:41PM +0200, Ian FREISLICH wrote: Pyun YongHyeon wrote: Thanks for the info. Frankly, I have no idea how to explain the issue given that you have no heavy load. How many cores would be involved in handling the traffic and runnig PF rules on this machine? There are 4x CPU: Quad-Core AMD Opteron(tm) Processor 8354 (2194.51-MHz K8-class CPU) In this server. I'm also using carp extensively. pf(4) uses a single lock for processing, number of core would have no much benefit. What's interesting is the effect on CPU utilisation and interrupt generation that net.inet.ip.fastforwarding has: net.inet.ip.fastforwarding=1 interrupt rate is around 1/s per bce interface cpu 8.0% interrupt Yes, this is one of intentional change of the patch. Stock bce(4) seems to generate too much interrupts on BCM5709 so I rewrote interrupt handling with the help of David. sysctl nodes are also exported to control interrupt moderation so you can change them if you want. Default value was tuned to generate interrupts less than 10k per second and try to minimize latencies. net.inet.ip.fastforwarding=0 interrupt rate is around 5000/s per bce interface cpu 13.0% interrupt It also appears to not drop packets, but I'll have to watch it for longer. Hmm, actually that's not what I originally expected. :-) The patch replaced some suspicious memory barrier instructions with bus_dmamap_sync(9) and you may see the effect. ___ 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: A tool for remapping bad sectors in CURRENT?
08.03.2010 13:29, Eugeny N Dzhurinsky пишет: Hello, all! Recently I've started to see the following logs in messages: Mar 8 12:00:24 localhost smartd[795]: Device: /dev/ad4, 2 Currently unreadable (pending) sectors Mar 8 12:00:24 localhost smartd[795]: Device: /dev/ad4, 2 Offline uncorrectable sectors smartctl did really show that something is wrong with my HDD, but still no remaps - just read errors. SMART Self-test log structure revision number 1 Num Test_DescriptionStatus Remaining LifeTime(hours) LBA_of_first_error # 1 Extended offlineCompleted: read failure 60% 1198 222342559 # 2 Extended offlineCompleted: read failure 60% 1187 222342557 # 3 Extended offlineCompleted: read failure 60% 1180 222342559 # 4 Short offline Completed without error 00% 1178 - # 5 Extended offlineAborted by host 90% 1178 - and ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE ... Reallocated_Sector_Ct 0x0033 100 100 036Pre-fail Always - 0 ... Now can I find out which file owns the LBAs 222342557 and 222342559 ? How do I force remapping of these sectors? I assume that I have to write something directly to the sectors? use mhdd ___ 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: Survey results very helpful, thanks! (was: Re: net.inet.tcp.timer_race: does anyone have a non-zero value?)
On 8 March 2010, at 06:53, Robert Watson wrote: On Sun, 7 Mar 2010, Robert Watson wrote: If your system shows a non-zero value, please send me a *private e-mail* with the output of that command, plus also the output of sysctl kern.smp, uptime, and a brief description of the workload and network interface configuration. For example: it's a busy 8-core web server with roughly X connections/second, and that has three em network interfaces used to load balance from an upstream source. IPSEC is used for management purposes (but not bulk traffic), and there's a local MySQL database. I've now received a number of reports that confirm our suspicion that the race does occur, albeit very rarely, and particularly on systems with many cores or multiple network interfaces. Fixing it is definitely on the TODO for 9.0, both to improve our ability to do multiple virtual network stacks, but with an appropriately scalable fix in mind given our improved TCP scalability for 9.0 as well. I run a number of 4 core systems with em interfaces. These are production systems that are unmanned and located a long way from me. Under unusual conditions it can take up to 6 hours to get there. I have been waiting to switch to 8.0 because of the discussions on the em device and now it sounds like I had better just skip 8.x and wait for 9. 7.2 is working just fine.___ 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: Survey results very helpful, thanks! (was: Re: net.inet.tcp.timer_race: does anyone have a non-zero value?)
On Mon, 8 Mar 2010, Doug Hardie wrote: I run a number of 4 core systems with em interfaces. These are production systems that are unmanned and located a long way from me. Under unusual conditions it can take up to 6 hours to get there. I have been waiting to switch to 8.0 because of the discussions on the em device and now it sounds like I had better just skip 8.x and wait for 9. 7.2 is working just fine. Not sure that any information in this survey thread should be relevant to that decision. This race has existed since before FreeBSD, having appeared in the original BSD network stack, and is just as present in FreeBSD 7.x as 8.x or 9.x. When I learned about the race during the early 7.x development cycle, I added a counter/statistic to measure how much it happened in practice, but was not able to exercise it in my testing, and so left the counter in to appear in 7.0 and later so that we could perform this survey as core counts/etc increase. The two likely outcomes were it is never exercised and it is exercised but only very infrequently, neither really justifying the quite complex change to correct it given requirements at the time. On-going development work on the virtual network stack is what justifies correcting the bug at this point, moving from detecting and handling the race to preventing it from occuring as an invariant. The motivation here, BTW, is that we'd like to eliminate the type-stable storage requirement for connection state (which ensures that memory once used for a connection block is only ever used for connection blocks in the future), allowing memory to be fully freed when a virtual network stack is destroyed. Using type-stable storage helped address this bug, but was primarily present to reduce the overhead of monitoring using netstat(1). We'll now need to use a slightly more expensive solution (true reference counts) in that context, although in practice it will almost certainly be an unmeasurable cost. Which is to say that while there might be something in the em/altq/... thread to reasonably lead you to avoid 8.0, nothing in the TCP timer race thread should do so, since it affects 7.2 just as much as 8.0. Even if you do see a non-zero counter, that's not a matter for operational concern, just useful from the perspective of a network stack developer to understanding timing and behaviors in the stack. :-) Robert ___ 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: Survey results very helpful, thanks!
Doug Hardie wrote: On 8 March 2010, at 06:53, Robert Watson wrote: On Sun, 7 Mar 2010, Robert Watson wrote: If your system shows a non-zero value, please send me a *private e-mail* with the output of that command, plus also the output of sysctl kern.smp, uptime, and a brief description of the workload and network interface configuration. For example: it's a busy 8-core web server with roughly X connections/second, and that has three em network interfaces used to load balance from an upstream source. IPSEC is used for management purposes (but not bulk traffic), and there's a local MySQL database. I've now received a number of reports that confirm our suspicion that the race does occur, albeit very rarely, and particularly on systems with many cores or multiple network interfaces. Fixing it is definitely on the TODO for 9.0, both to improve our ability to do multiple virtual network stacks, but with an appropriately scalable fix in mind given our improved TCP scalability for 9.0 as well. I run a number of 4 core systems with em interfaces. These are production systems that are unmanned and located a long way from me. Under unusual conditions it can take up to 6 hours to get there. I have been waiting to switch to 8.0 because of the discussions on the em device and now it sounds like I had better just skip 8.x and wait for 9. 7.2 is working just fine.___ I don't think its that simple. I run a number of production systems with em interfaces, and they get POUNDED. None have had any trouble with 8.x. $ ifconfig em0 em0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST metric 0 mtu 1500 options=19bRXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,TSO4 ether 00:30:48:d2:5a:24 inet 67.23.181.70 netmask 0xff00 broadcast 67.23.181.255 media: Ethernet autoselect (100baseTX full-duplex) status: active $ uptime 3:27PM up 61 days, 22:34, 1 user, load averages: 5.08, 4.48, 4.28 That's one of the busier ones; it's kinda loafing right now on network I/O (running about 3mbps sustained) but typically operates in the 15-20mbps range to the wild wild net for 6-8 hours in the evening doing what its doing now (handling a very busy forum) plus a few hundred videocast streams The last reboot was to replace a power strip in the colo rack with one that had remote management capability. It hasn't actually crashed since, well, pretty much forever (it was running 7.x before 8.x went to production status) The box is a dual quad-core Xeon running the amd64 codebase. -- Karl ___ 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: Core i5 AES acceleration
Hi David. On Sun, 07 Mar 2010 09:59:07 -0800 David Ehrmann ehrm...@gmail.com wrote: I was thinking that if I did do it, I'd start with padlock as a base. It looks like there are maybe 6 new opcodes. Maybe we could ask the contributor of the Linux code (an Intel employee) if he'd be willing to also release the code under a BSD license. According to http://en.wikipedia.org/wiki/AES-NI , we can get specification document: http://software.intel.com/file/20457 . I saw it, and consider that we can release under BSDL. Because of 'from specification'. My problem is that I don't have a Core i5 system--I was asking because it's an option for my new system--and I'm far from an x86 assembly expert. I have a machine equipped with Core i7 640UM, so I'll be able to test. But I'm far from an x86asm expert, too:-(. ___ 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: Core i5 AES acceleration
Norikatsu Shigemura wrote: According to http://en.wikipedia.org/wiki/AES-NI , we can get specification document: http://software.intel.com/file/20457 . I saw it, and consider that we can release under BSDL. Because of 'from specification'. That document is short on details, such as the opcodes and machine implementation details (flags, etc). The XMM registers are used. That may be a problem for kernel code. When last I looked openssl did not use /dev/crypt - it's not clear how big the benefit would be from doing this if nothing that uses openssl wins. It might be more beneficial to FreeBSD to patch openssl to use /dev/crypt. If it turns out to not be a significant win then that might hint that the AES opcodes won't be significant win in general either. ___ 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: Core i5 AES acceleration
On Mon, Mar 8, 2010 at 4:10 PM, James R. Van Artsdalen james-freebsd-curr...@jrv.org wrote: When last I looked openssl did not use /dev/crypt - it's not clear how big the benefit would be from doing this if nothing that uses openssl wins. Geli uses the crypto framework. ___ 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: Problem with new bwn driver on -CURRENT
On Sun, Mar 07, 2010 at 12:05:43AM -0500, Joe Marcus Clarke wrote: On Fri, 2010-03-05 at 16:16 -0800, Weongyo Jeong wrote: On Fri, Mar 05, 2010 at 04:44:34PM -0500, Joe Marcus Clarke wrote: On 3/5/10 3:53 PM, Weongyo Jeong wrote: On Thu, Mar 04, 2010 at 12:12:02AM -0500, Joe Marcus Clarke wrote: On Wed, 2010-03-03 at 15:14 -0800, Weongyo Jeong wrote: When it occurs again, I will get you the details and the full dmesg. Do you want a verbose dmesg, or a standard one? I think a standard one is enough. Thank you. Here you go. This is on -CURRENT from about 30 minutes ago. Thanks for looking into this. http://www.marcuscom.com/downloads/salami.dmesg Thank you for dmesg. It looks using PIO mode is only a way to avoid this problem. I looked sources and problems of other Broadcom wireless driver for LP PHY users. They also encounters this issue and are trying to solve this but no luck and no perfect patch until now. Recently AFAIK wireless-test git of linux adopted a patch `gracefully convert DMA to PIO mode' to solve it. Additionally some guys tolds some success story when they disabled ACPI but it looks it's not a perfect solution. IIRC you said PIO worked for association with your AP but no further traffic. However I wonder that this is weird for me because paths of sending management frames and sending data frames are same. Could you please recheck whether PIO mode worked? I'll try to test PIO mode on my environment again. I can absolutely confirm PIO mode does NOT work with my card. I tested on a clean power-up. The card associates, but does not pass any traffic. I do not see the same decryption messages that I do with DMA mode. OK. I'd like to see some verbose message from bwn(4) after applying attached patch with email. Could you please test with it and show me dmesg? I tested 3 broadcom card whose revisions are 5 and 9 and it looks it's working. I have one LP PHY device, half MiniPCI-E for laptop, but could not test with this patch because I could not turn on RF; it's connected with desktop using converter MiniPCI-E to PCI-E though normally it looks MiniPCI-E devices are turned on using H/W RF switch. Here are two dmesg outputs. Both were taken with this patch. One is with PIO mode, and the other is with (working) DMA mode. The names indicate which is which. http://www.marcuscom.com/downloads/salami_pio.dmesg http://www.marcuscom.com/downloads/salami_dma.dmesg Thank you for dmesg. It looks you are right that your device in PIO mode doesn't work. Specially RX path is weird that it was good until the status is changed to RUN but after querying DHCP requests (or another) there were no more RX events (seems no more frames ready). I think it'd be better to file a PR because I could not test LP PHY easily and it looks that it takes time to solve this problem. Could you please do that? regards, Weongyo Jeong ___ 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
