Re: Duplicate IPFW rules
Hello! On Thu, 21 Dec 2006, Vclav Haisman wrote: One example feature is to be able to delete many rules at once. If you know that a specific rule number holds rules (example: time based rules) then the script has less work to do. Now granted since sets where introduced this can be done via this method but this feature has been useful (at least to me) for years and years now. Scott Oh, I did not realise this use. Hmm...still, I thought that this is what tables are for :) The ability to have several distinct ipfw rules with the same rule_number is also useful for the purposes of traffic accounting. Say, you should tally traffic received via some interface + traffic from the proxy-server together for some user: ipfw add 3000 count all from any to user in recv ext0 ipfw add 3000 count tcp from proxy 3128 to user out and just teach the traffic accounting utility to sum up byte counts for the rules with the same number. Very handy, and not doable via lookup tables. VH Sincerely, Dmitry -- Atlantis ISP, System Administrator e-mail: [EMAIL PROTECTED] nic-hdl: LYNX-RIPE ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
[summary] Re: burncd 'blank' not terminating ?
summary: there was some discussion on how to
fix the problem, in 6.x, with burncd -f /dev/acd0 -v blank getting
stuck with this message
blanking CD, please wait..
This used to work on 4.x.
6.x changes in two places:
* the ioctl handler, acd_get_progress() in /sys/dev/ata/atapi-cd.c
does a much stricter error checking, expecting the ATA_SENSE_VALID
bit set in response to the ATAPI_READ_CAPACITY call.
None of my DVD drives do that:
acd0: DVDR HL-DT-ST DVDRAM GSA-4163B/A101 at ata1-master UDMA33
acd0: DVDR HL-DT-ST DVDRAM GSA-H10N/JL10 at ata0-slave UDMA33
even though they do report a valid progress status if you disable
the check for ATA_SENSE_VALID, and in fact they do work under 4.x
* usr.sbin/burncd/burncd.c waits for a transition of CDRIOCGETPROGRESS
from 90..99 to 0, which fails to be detected because the ioctl()
always returns 0 when ATA_SENSE_VALID is not set.
In private mail, Soren mentioned that the spec (whatever it is called)
says that the ATA_SENSE_VALID 'shall be set' when returning a valid value,
so he is slightly dubious on removing the check in atapi-cd.c
Also, it seems that the proper way to check for completion is to issue
the TEST UNIT READY command, which is accessible through the CDIOCRESET
ioct.
I suggest the following two fixes:
1. change burncd.c as below, so that if CDRIOCGETPROGRESS does not return
anything good, it calls CDIOCRESET to determine when the command
is complete.
This can be improved by calling CDIOCRESET unconditionally as a
termination test
2. change atapi-cd.c to return something even if ATA_SENSE_VALID is
unset. Apparently there is a lot of non-complying hardware around
so restricting to what the spec says is like shooting ourselves
in the foot.
Again, if burncd.c uses CDIOCRESET to determine the completion
of the 'blank' operation, we don't care if the return value from
CDRIOCGETPROGRESS is incorrect, because we don't rely on it.
Patches below (to be improved to make CDIOCRESET unconditional).
Does this satisfy all ?
cheers
luigi
Index: burncd.c
===
RCS file: /home/ncvs/src/usr.sbin/burncd/burncd.c,v
retrieving revision 1.45
diff -u -r1.45 burncd.c
--- burncd.c13 May 2005 20:06:44 - 1.45
+++ burncd.c26 Dec 2006 12:32:29 -
@@ -188,6 +188,7 @@
if ((!strcasecmp(argv[arg], erase) ||
!strcasecmp(argv[arg], blank)) !test_write) {
int blank, pct, last = 0;
+ int sec = 0;
if (!strcasecmp(argv[arg], erase))
blank = CDR_B_ALL;
@@ -200,15 +201,20 @@
if (ioctl(fd, CDRIOCBLANK, blank) 0)
err(EX_IOERR, ioctl(CDRIOCBLANK));
while (1) {
+ int done = -1;
sleep(1);
+ sec++;
+ pct = 0;
if (ioctl(fd, CDRIOCGETPROGRESS, pct) == -1)
err(EX_IOERR,ioctl(CDRIOGETPROGRESS));
- if (pct 0 !quiet)
+ if (pct == 0)
+ done = ioctl(fd, CDIOCRESET, NULL);
+ if (!quiet)
fprintf(stderr,
- %sing CD - %d %% done \r,
+ %sing CD - %3dsec %d %% done
%d\r,
blank == CDR_B_ALL ?
- eras : blank, pct);
- if (pct == 100 || (pct == 0 last 90))
+ eras : blank, sec, pct,
done);
+ if (pct == 100 || (pct == 0 last 90) ||
done == 0)
break;
last = pct;
}
Index: atapi-cd.c
===
RCS file: /home/ncvs/src/sys/dev/ata/atapi-cd.c,v
retrieving revision 1.179.2.7
diff -u -r1.179.2.7 atapi-cd.c
--- atapi-cd.c 2 Sep 2006 17:01:32 - 1.179.2.7
+++ atapi-cd.c 24 Dec 2006 10:38:01 -
@@ -1234,7 +1234,7 @@
request-flags = ATA_R_ATAPI | ATA_R_READ;
request-timeout = 30;
ata_queue_request(request);
-if (!request-error request-u.atapi.sense.error ATA_SENSE_VALID)
+if (!request-error request-u.atapi.sense.error)
*finished = ((request-u.atapi.sense.specific2 |
(request-u.atapi.sense.specific1 8)) * 100) / 65535;
else
___
freebsd-stable@freebsd.org mailing list
Re: deadlock in zoneli state on 6.2-PRERELEASE
On Monday, 25 December 2006 at 13:23:17 +0800, LI Xin wrote: Hi, Nikolay, Our local customer has applied the following and it seems to have 'solved' their problem on squid: echo kern.ipc.nmbclusters=0 /boot/loader.conf and then reboot. They have been running with the 20061212 patch but I suspect that it's no longer necessary. The feedback I have received is that they have run with this for two weeks without problem, serving video streams. Please let us know if this works. Wish you a happy new year :-) Thanks. Still no luck with my problem :) It dies for me somewhere about: [EMAIL PROTECTED]:~# netstat -m 208965/585/209550 mbufs in use (current/cache/total) 208432/474/208906/0 mbuf clusters in use (current/cache/total/max) 208432/464 mbuf+clusters out of packet secondary zone in use (current/cache) 0/0/0/0 4k (page size) jumbo clusters in use (current/cache/total/max) 0/0/0/0 9k jumbo clusters in use (current/cache/total/max) 0/0/0/0 16k jumbo clusters in use (current/cache/total/max) 469105K/1094K/470199K bytes allocated to network (current/cache/total) 0/0/0 requests for mbufs denied (mbufs/clusters/mbuf+clusters) 0/0/0 requests for jumbo clusters denied (4k/9k/16k) 0/3/6656 sfbufs in use (current/peak/max) 0 requests for sfbufs denied 0 requests for sfbufs delayed 0 requests for I/O initiated by sendfile 0 calls to protocol drain routines With panic: kmem_malloc(4096): kmem_map too small: 536870912 total allocated So there is still memory leak somewhere or i have some rarely and hardly detectable hardware bug. At least all other squid servers on this load balancer cluster works fine even under same load as this box and there is no any mbuf related problems on them. In any case thank you and all folks for help :) Happy holidays! Cheers, -- Xin LI [EMAIL PROTECTED]http://www.delphij.net/ FreeBSD - The Power to Serve! -- == - Best regards, Nikolay Pavlov. --- == ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
fdformat usb floppy disks not supported on 6.x ?
is there any way to fdformat a floppy connected through usb ? luigi# fdformat da0 fdformat: not a floppy disk: /dev/da0 i am running a RELENG_6 from Dec.23 sources, and the device is the following: Dec 26 17:12:09 luigi kernel: umass0: MITSUMI MITSUMI USB FDD, rev 1.00/1.00, addr 2 Dec 26 17:12:09 luigi kernel: da0 at umass-sim0 bus 0 target 0 lun 0 Dec 26 17:12:09 luigi kernel: da0: MITSUMI USB FDD 1033 Removable Direct Access SCSI-0 device Dec 26 17:12:09 luigi kernel: da0: 1.000MB/s transfers cheers luigi ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Status of FreeBSD 6.2?
I haven't seen much on the lists lately regarding the status of FreeBSD 6.2, so I'd like to ask the Release Engineering team for their thoughts and projections. The calendar on the public Release Engineering page hasn't been updated since November, and those of us who await 6.2-RELEASE need to have some idea of what to expect. I don't know about everyone else, but I for one would not like to see the release rushed; in fact, I'd rather have it delayed a little if it means that some longstanding PRs will be cleared up. However, I do need to know how things are progressing. When are we likely to see an RC2? Given the many changes to the code since RC1, will there be an RC3? When will the calendar and to do list be updated? And will we see a release by, say, Valentine's Day? --Brett Glass ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Status of FreeBSD 6.2?
On Tuesday, 26 December, 2006 at 11:54:51 -0700, Brett Glass wrote: I haven't seen much on the lists lately regarding the status of FreeBSD 6.2, so I'd like to ask the Release Engineering team for their thoughts and projections. The calendar on the public Release Engineering page hasn't been updated since November, and those of us who await 6.2-RELEASE need to have some idea of what to expect. Really? http://www.freebsd.org/releng/index.html claims: Last modified: 2006/12/08 17:09:58. And http://www.freebsd.org/releases/6.2R/schedule.html claims: Last modified: 2006/12/25 02:18:37. I'm not part of RE or even the very hard working FreeBSD team, but I do follow cvs-all@ and so did notice the commit to schedule.html yesterday. I'm sure they are all doing their best to make 6.2 the best possible release they can. Seasons greetings. Cheers, Nick. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Status of FreeBSD 6.2?
Nick Mann Writes: Really? http://www.freebsd.org/releng/index.htmlhttp://www.freebsd.org/releng/index.html claims: Last modified: 2006/12/08 17:09:58. True. But it still lists the release date for 6.2 as Mid-December. And http://www.freebsd.org/releases/6.2R/schedule.htmlhttp://www.freebsd.org/releases/6.2R/schedule.html claims: Last modified: 2006/12/25 02:18:37. Also true. But it still shows a projected release date of 13 November! I'm not asking that the release be rushed; I'm asking that the projections, to-do lists, etc. be updated so that we who are anticipating it have some idea of the RE team's plans going into the new year. Even if the release date is in February, that's fine -- just so it makes for a better product and we can anticipate and plan for it. --Brett Glass ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re[2]: Status of FreeBSD 6.2?
Hello Brett, Tuesday, December 26, 2006, 9:51:11 PM, you wrote: I'm not asking that the release be rushed; I'm asking that the projections, to-do lists, etc. be updated so that we who are anticipating it have some idea of the RE team's plans going into the new year. Even if the release date is in February, that's fine -- just so it makes for a better product and we can anticipate and plan for it. 6.2-RC2 builds already started. --Brett Glass -- Best regards, Danielmailto:[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: Status of FreeBSD 6.2?
At 02:05 PM 12/26/2006, Ronald Klop wrote: The schedules says. Build 6.2-RC2 24 December 2006Begin building the second release candidate build for all Tier-1 platforms. On what page does it say that? Perhaps our cache still has a copy of an old page, though this would be unusual since it normally errs on the side of expiring pages too quickly. --Brett Glass ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [summary] Re: burncd 'blank' not terminating ?
Luigi Rizzo [EMAIL PROTECTED] writes: summary: there was some discussion on how to fix the problem, in 6.x, with burncd -f /dev/acd0 -v blank getting stuck with this message blanking CD, please wait.. This used to work on 4.x. [ .. stuff deleted .. ] Patches below (to be improved to make CDIOCRESET unconditional). Does this satisfy all ? great! Works for me. (and even cdrecord now works). Thanx a lot. Arno P.S. this fixes, for real, http://www.freebsd.org/cgi/query-pr.cgi?pr=94426 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Status of FreeBSD 6.2?
Build 6.2-RC2 24 December 2006Begin building the second release candidate build for all Tier-1 platforms. http://www.freebsd.org/releases/6.2R/schedule.html Martin ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Status of FreeBSD 6.2?
On Tue, 26 Dec 2006 21:51:11 +0100, Brett Glass [EMAIL PROTECTED] wrote: Nick Mann Writes: Really? http://www.freebsd.org/releng/index.htmlhttp://www.freebsd.org/releng/index.html claims: Last modified: 2006/12/08 17:09:58. True. But it still lists the release date for 6.2 as Mid-December. And http://www.freebsd.org/releases/6.2R/schedule.htmlhttp://www.freebsd.org/releases/6.2R/schedule.html claims: Last modified: 2006/12/25 02:18:37. Also true. But it still shows a projected release date of 13 November! I'm not asking that the release be rushed; I'm asking that the projections, to-do lists, etc. be updated so that we who are anticipating it have some idea of the RE team's plans going into the new year. Even if the release date is in February, that's fine -- just so it makes for a better product and we can anticipate and plan for it. --Brett Glass The schedules says. Build 6.2-RC2 24 December 2006 Begin building the second release candidate build for all Tier-1 platforms. So that answers part one of your questions. I don't know anything about the expected release date. Ronald. -- Ronald Klop Amsterdam, The Netherlands ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Background fsck causes kernel panic
Running a fairly recent RELENG_6 SMP kernel, I had a nasty experience
where filesystem corruption on a pair of RAID5 volumes on an arcmsr
would cause the machine to panic during the background fsck. This
resulted in a merry crash-reboot-crash cycle until I booted on to an
install CD, ran a foreground fsck and fixed the errors.
Given that this machine *is* a file server I'm rather eager to make sure
the problem doesn't happen again.
I'm not familiar with the code at all, but all three panics look like they're
happening in soft-update sections:
Unread portion of the kernel message buffer:
panic: softdep_setup_freeblocks: inode busy
cpuid = 0
Uptime: 4h58m59s
Dumping 1023 MB (2 chunks)
chunk 0: 1MB (159 pages) ... ok
chunk 1: 1023MB (261872 pages) 1007 991 975 959 943 927 911 895 879 863 847
831 815 799 783 767 751 735 719 703 687 671 655 639 623 607 591 575 559 543 527
511 495 479 463 447 431 415 399 383 367 351 335 319 303 287 271 255 239 223 207
191 175 159 143 127 111 95 79 63 47 31 15
#0 doadump () at pcpu.h:165
165 __asm __volatile(movl %%fs:0,%0 : =r (td));
(kgdb) where
#0 doadump () at pcpu.h:165
#1 0xc061e541 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:409
#2 0xc061e934 in panic (fmt=0xc0905fc5 softdep_setup_freeblocks: inode busy)
at /usr/src/sys/kern/kern_shutdown.c:565
#3 0xc07bb7f9 in softdep_setup_freeblocks (ip=0xc6002c60, length=Unhandled
dwarf expression opcode 0x93
) at /usr/src/sys/ufs/ffs/ffs_softdep.c:2271
#4 0xc07ae85d in ffs_truncate (vp=0xc5fff000, length=0, flags=3072, cred=0x0,
td=0xc531b180) at /usr/src/sys/ufs/ffs/ffs_inode.c:278
#5 0xc07d0abe in ufs_inactive (ap=0x0) at /usr/src/sys/ufs/ufs/ufs_inode.c:126
#6 0xc08b364e in VOP_INACTIVE_APV (vop=0x0, a=0x0) at vnode_if.c:1535
#7 0xc068faf2 in vinactive (vp=0xc5fff000, td=0x0) at vnode_if.h:795
#8 0xc068f81c in vput (vp=0xc5fff000) at /usr/src/sys/kern/vfs_subr.c:2158
#9 0xc0697539 in kern_unlink (td=0xc531b180, path=0xbfbfe4b0 Address
0xbfbfe4b0 out of bounds, pathseg=UIO_USERSPACE) at
/usr/src/sys/kern/vfs_syscalls.c:1722
#10 0xc0697322 in unlink (td=0x0, uap=0x0) at
/usr/src/sys/kern/vfs_syscalls.c:1658
#11 0xc089d6f0 in syscall (frame=
{tf_fs = -1078001605, tf_es = 135528507, tf_ds = -1078001605, tf_edi = 1,
tf_esi = 135534336, tf_ebp = -1077942072, tf_isp = -412762780, tf_ebx =
135461640, tf_edx = 0, tf_ecx = 5, tf_eax = 10, tf_trapno = 0, tf_err = 2,
tf_eip = 674363207, tf_cs = 51, tf_eflags = 642, tf_esp = -1077944196, tf_ss =
59}) at /usr/src/sys/i386/i386/trap.c:983
#12 0xc088501f in Xint0x80_syscall () at /usr/src/sys/i386/i386/exception.s:200
#13 0x0033 in ?? ()
Previous frame inner to this frame (corrupt stack?)
I've filed a PR about it (which has two more backtraces):
http://www.freebsd.org/cgi/query-pr.cgi?pr=107206
Can anyone suggest further action?
--Geoff
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Status of FreeBSD 6.2?
On Tue, Dec 26, 2006 at 10:05:34PM +0100, Ronald Klop wrote.. On Tue, 26 Dec 2006 21:51:11 +0100, Brett Glass [EMAIL PROTECTED] wrote: Nick Mann Writes: Really? http://www.freebsd.org/releng/index.htmlhttp://www.freebsd.org/releng/index.html claims: Last modified: 2006/12/08 17:09:58. True. But it still lists the release date for 6.2 as Mid-December. And http://www.freebsd.org/releases/6.2R/schedule.htmlhttp://www.freebsd.org/releases/6.2R/schedule.html claims: Last modified: 2006/12/25 02:18:37. Also true. But it still shows a projected release date of 13 November! I'm not asking that the release be rushed; I'm asking that the projections, to-do lists, etc. be updated so that we who are anticipating it have some idea of the RE team's plans going into the new year. Even if the release date is in February, that's fine -- just so it makes for a better product and we can anticipate and plan for it. --Brett Glass The schedules says. Build 6.2-RC2 24 December 2006Begin building the second release candidate build for all Tier-1 platforms. So that answers part one of your questions. I don't know anything about the expected release date. FYI: RC2 builds have been mostly done. They are or are on their way, to ftp-master as we speak. The fact that ftp-master suffered a hardware failure that required a replacement machine be brought online did not really help. Thanks to Peter a.o. for their work to get that replacement machine online. -- Wilko Bulte [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: fdformat usb floppy disks not supported on 6.x ?
Luigi Rizzo wrote: is there any way to fdformat a floppy connected through usb ? I have the bits to do this, though they aren't finished, so I never committed them: http://people.freebsd.org/~bms/dump/ufdformat/ Further testing on this was entrusted to Cy Schubert... Regards, BMS ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [summary] Re: burncd 'blank' not terminating ?
Luigi Rizzo wrote: summary: there was some discussion on how to fix the problem, in 6.x, with burncd -f /dev/acd0 -v blank getting stuck with this message blanking CD, please wait.. This used to work on 4.x. 6.x changes in two places: * the ioctl handler, acd_get_progress() in /sys/dev/ata/atapi-cd.c does a much stricter error checking, expecting the ATA_SENSE_VALID bit set in response to the ATAPI_READ_CAPACITY call. None of my DVD drives do that: acd0: DVDR HL-DT-ST DVDRAM GSA-4163B/A101 at ata1-master UDMA33 acd0: DVDR HL-DT-ST DVDRAM GSA-H10N/JL10 at ata0-slave UDMA33 even though they do report a valid progress status if you disable the check for ATA_SENSE_VALID, and in fact they do work under 4.x * usr.sbin/burncd/burncd.c waits for a transition of CDRIOCGETPROGRESS from 90..99 to 0, which fails to be detected because the ioctl() always returns 0 when ATA_SENSE_VALID is not set. In private mail, Soren mentioned that the spec (whatever it is called) says that the ATA_SENSE_VALID 'shall be set' when returning a valid value, so he is slightly dubious on removing the check in atapi-cd.c Also, it seems that the proper way to check for completion is to issue the TEST UNIT READY command, which is accessible through the CDIOCRESET ioct. I suggest the following two fixes: 1. change burncd.c as below, so that if CDRIOCGETPROGRESS does not return anything good, it calls CDIOCRESET to determine when the command is complete. This can be improved by calling CDIOCRESET unconditionally as a termination test FWIW just checking with TEST UNIT READY in general for progress will fail for lots of devices, but it might be that those have prober progress reporting so the sum of doing both is of benefit. 2. change atapi-cd.c to return something even if ATA_SENSE_VALID is unset. Apparently there is a lot of non-complying hardware around so restricting to what the spec says is like shooting ourselves in the foot. As I mentioned lots of devices does return garbage there so its more a question on which pool of devices you want to have working and which you wont, so its not a solution, rather a decision on which devices to support properly, I chose those that follow specs. Again, if burncd.c uses CDIOCRESET to determine the completion of the 'blank' operation, we don't care if the return value from CDRIOCGETPROGRESS is incorrect, because we don't rely on it. Right, but that will leave out reporting of progress which has been asked for lots of times since some of this takes time. As usual there is no easy solution, its a question on which devices work and which wont, and that unfortunatly changes over time... -Søren ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [summary] Re: burncd 'blank' not terminating ?
On Wed, Dec 27, 2006 at 02:33:15AM +0100, Søren Schmidt wrote: Luigi Rizzo wrote: summary: there was some discussion on how to fix the problem, in 6.x, with burncd -f /dev/acd0 -v blank getting stuck with this message blanking CD, please wait.. This used to work on 4.x. 6.x changes in two places: * the ioctl handler, acd_get_progress() in /sys/dev/ata/atapi-cd.c does a much stricter error checking, expecting the ATA_SENSE_VALID bit set in response to the ATAPI_READ_CAPACITY call. None of my DVD drives do that: acd0: DVDR HL-DT-ST DVDRAM GSA-4163B/A101 at ata1-master UDMA33 acd0: DVDR HL-DT-ST DVDRAM GSA-H10N/JL10 at ata0-slave UDMA33 even though they do report a valid progress status if you disable the check for ATA_SENSE_VALID, and in fact they do work under 4.x * usr.sbin/burncd/burncd.c waits for a transition of CDRIOCGETPROGRESS from 90..99 to 0, which fails to be detected because the ioctl() always returns 0 when ATA_SENSE_VALID is not set. In private mail, Soren mentioned that the spec (whatever it is called) says that the ATA_SENSE_VALID 'shall be set' when returning a valid value, so he is slightly dubious on removing the check in atapi-cd.c Also, it seems that the proper way to check for completion is to issue the TEST UNIT READY command, which is accessible through the CDIOCRESET ioct. I suggest the following two fixes: 1. change burncd.c as below, so that if CDRIOCGETPROGRESS does not return anything good, it calls CDIOCRESET to determine when the command is complete. This can be improved by calling CDIOCRESET unconditionally as a termination test FWIW just checking with TEST UNIT READY in general for progress will fail for lots of devices really ? i thought it was the standard way to test for completion (i don't have access to a recent atapi-X spec other than this SFF-8020i r2.6 - circa 1996). But i see you have put a workaround in act_fixate(), presumably for a similar behaviour. progress reporting so the sum of doing both is of benefit. 2. change atapi-cd.c to return something even if ATA_SENSE_VALID is unset. Apparently there is a lot of non-complying hardware around so restricting to what the spec says is like shooting ourselves in the foot. As I mentioned lots of devices does return garbage there so its more a question on which pool of devices you want to have working and which you wont, so its not a solution, rather a decision on which devices to support properly, I chose those that follow specs. a few comments: 1. we don't need to limit ourselves to support only one type of devices; and given the large set of non-compliant devices (basically all the ones i have!) at the very least we should have a user-settable sysctl (to ignore the ATA_SENSE_VALID bit) or a burncd option (to trust TEST UNIT READY). I'd rather not use quirks because the list might become huge. 2. these same non-compliant devices used to work on 4.x, so people will really perceive this as a regression, which is not good from a PR perspective; 3. again i have an old copy of the spec (SFF-8020i), but the description of the ATA_SENSE_VALID is ambiguous - it says (Table 137-Request Sense Standard Data) A Valid bit of zero indicates that the information field is not as defined in this specification. A Valid bit of one indicates the information field contains valid information as defined in this Specification. ATAPI CD-ROM drives shall implement the Valid bit So, it doesn't say the bit _must_ be '1', and i can imagine implementors that slightly deviate from the standard formatting (e.g. adding fields etc. ) setting the bit to 0. Yet, we could at least pass the info up to userland (including the VALID bit) and let the application decide what to do with it. Again, if burncd.c uses CDIOCRESET to determine the completion of the 'blank' operation, we don't care if the return value from CDRIOCGETPROGRESS is incorrect, because we don't rely on it. Right, but that will leave out reporting of progress which has been asked for lots of times since some of this takes time. the way i have it now, i do both CDRIOCGETPROGRESS and CDIOCRESET, using either one as a termination signal. cheers luigi ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: chkrootkit finds 94 process hidden for readdir
On Sat, Dec 23, 2006 at 03:57:35PM -0500, Matthew Herzog wrote: Hello. I run FreeBSD 6.1-RELEASE-p7 on an UltraSparc 5 machine. I ran chkrootkit yesterday and saw this: Checking `lkm'... You have94 process hidden for readdir command chkproc: Warning: Possible LKM Trojan installed Everything else was deemed clean by chkrootkit. When I booted into single user mode and ran chkrootkit it said there were 33 process hidden for readdir command The sha256 checksum is slightly different for the /usr/bin/su binary on the install media compared to the /usr/bin/su on the running install. I could find nothing definitive on this subject posted online so . . . . Most likely this is just another false positive with this inherently unreliable problem. Kris pgpuVQ6v1SgXl.pgp Description: PGP signature
Re: Background fsck causes kernel panic
On Wed, Dec 27, 2006 at 09:54:11AM +1100, Geoffrey Giesemann wrote: Running a fairly recent RELENG_6 SMP kernel, I had a nasty experience where filesystem corruption on a pair of RAID5 volumes on an arcmsr would cause the machine to panic during the background fsck. This resulted in a merry crash-reboot-crash cycle until I booted on to an install CD, ran a foreground fsck and fixed the errors. Yes, this is the danger when running bg fsck and your system experiences a panic or other non-softupdates-safe source of filesystem corruption. As you discovered, the solution is to force a fsck to repair all corruption and then proceed (optionally disabling bg fsck permanently to prevent a recurrence ;-) Kris pgpVAxa3riIfC.pgp Description: PGP signature
Re: swap_pager loop?
On Tue, Dec 19, 2006 at 07:40:16AM -0500, Ken Sallot wrote: Greetings, Yesterday morning I came in to find a 6.2-RC1 server deadlocked in a loop with the following error messages on the console: swap_pager: indefinite wait buffer: bufobj: 0, blkno: 5, size: 4096 swap_pager: indefinite wait buffer: bufobj: 0, blkno: 13, size: 4096 swap_pager: indefinite wait buffer: bufobj: 0, blkno: 5, size: 4096 swap_pager: indefinite wait buffer: bufobj: 0, blkno: 13, size: 4096 The machine has 4gb of ram, a 4gb swap partition on /dev/amrd0s1b, and provides nfs/nis/samba/printing (cups) services. This issue appears to have been open since at least 6.1-RELEASE, and I was wondering if anyone had a work-around that we can use for the time being. You could try increasing the timeout in the msleep() in vm/swap_pager.c. If your system is just so heavily loaded that the I/O command really is taking more than 20 seconds to complete, you may be getting false positives. If you continue to get the warning with an arbitrarily large timeout, then you really are losing I/O transactions and need to look carefully at your hardware, swap configuration and (someone) at the drivers. Kris pgppV5sBDswu7.pgp Description: PGP signature
