Re: Trouble with a atapi-cam backup..
* Randy Stewart, 2010-09-02 : And now my backup to atapi-cam is failing.. I get: r...@lakerest /usr/tmp]# /usr/local/bin/growisofs -Z /dev/cd0 -R -J backup_init.08-31-2010.gz :-( unable to CAMGETPASSTHRU for /dev/cd0: Inappropriate ioctl for device Would be interesting to see the output of truss or ktrace for this command. Can you open a PR and send that info? Does camcontrol inq cd0 work? Thomas. ___ 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: Repeatable panic from 'camcontrol devlist'
* Greg 'groggy' Lehey, 2003-10-27 : I'm running a -CURRENT kernel built about a week ago, and on 'camcontrol devlist' I get the following repeatable panic: Fixed in vfs_bio.c rev. 1.418. Thomas. -- [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: atapicam related panic
* Stuart Walsh, 2003-10-18 : I have an easily reproducable panic when using atapicam. Vague trace This has nothing to do whatsoever with ATAPI/CAM! this is an inconsistency between cam_periph.c and vfs_bio.c, you need to update the latter to rev. 1.418 or newer. Thomas. -- [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: CDROM / UDMA problem on -current (2 hours old)
Le 2003-10-06, Jan Stocker écrivait : I would give you more info... but as i wrote... thats an endless loop. You might be able to interrupt the loop by breaking into DDB with Crtl+Alt+Esc, which then allows you to get a backtrace. interesting to know whether the enclosed patch changes anything to your situation. Will try it. Pls give me some mins (~30) Thanks! Thomas. -- [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: CDROM / UDMA problem on -current (2 hours old)
Le 2003-10-06, Jan Stocker écrivait : But here some stuff when booting in safe mode (maybe it boots because DMA support for atapi is off, have to check) Probably so. The messages you quote look perfectly normal. Thomas. -- [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: CDROM / UDMA problem on -current (2 hours old)
Le 2003-10-04, Jan Stocker écrivait :
are printed so fast i cant really read but it must be something
like that:
acd1: WARNING - REQUEST_UDMA (error request)
acd1: WARNING - INQUIRE_SENSE (retrying request)
Little can be said without complete and accurate error messages,
preferrably including a complete kernel backtrace, but still it would be
interesting to know whether the enclosed patch changes anything to your
situation.
Thomas.
Index: ata-queue.c
===
RCS file: /home/ncvs/src/sys/dev/ata/ata-queue.c,v
retrieving revision 1.6
diff -u -r1.6 ata-queue.c
--- ata-queue.c 19 Sep 2003 12:46:12 - 1.6
+++ ata-queue.c 5 Oct 2003 22:56:28 -
@@ -223,7 +223,7 @@
/* if this is a UDMA CRC error, retry request */
if (request-flags ATA_R_DMA request-error ATA_E_ICRC) {
- if (request-retries--) {
+ if (request-retries-- 0) {
ata_prtdev(request-device,
WARNING - %s UDMA ICRC error (retrying request)\n,
ata_cmd2str(request));
--
[EMAIL PROTECTED]
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: CDROM / UDMA problem on -current (2 hours old)
Le 2003-10-05, Jan Stocker écrivait : /usr/local/bin/cdrecord: Permission denied. Cannot send SCSI cmd via ioctl Check perms on your /dev nodes. Thomas. -- [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: CDROM / UDMA problem on -current (2 hours old)
Le 2003-10-05, Jan Stocker écrivait : it's an atapicam problem... That we do not know so far. Recent problems reported by ATAPI/CAM users were mostly ATA and CAM bugs. Please do not make such hasty statements until a complete analysis of the problem has been made. Thanks, Thomas. -- [EMAIL PROTECTED] pgp0.pgp Description: PGP signature
Re: acd0 vs cd0 (ATAPICAM)
Le 2003-09-19, Guillaume écrivait : Thanks for the patch. cd0 is faster now and ATAPICAM works great. Are you going to commit the patch? DMA is now enabled for ATAPI/CAM i/o, as of atapi-cam.c rev. 1.26. Thanks to all who tested and reviewed the change. Thomas. -- [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ATAng no good for me/REQUEST_SENSE recovered from missing interrupt
Le 2003-09-22, Dan Naumov écrivait : Speaking of failing, should I completely disregard the probe2:ata1 warnings during boot which you saw in the dmesg output I sent you ? Yes, these messages are perfectly inocuous, they mean that your CD drive does not provide serial number information. You can safely ignore them. -- [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: atapicam error messages at boot/appears to work nonetheless
Le 2003-09-22, Matthias Andree écrivait : I'm getting complaints from ata or atapicam during boot-up, but my From CAM actually, and you can safely ignore them. Thomas. -- [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: atapicam and dvd-r(w)
Le 2003-09-21, Sascha Holzleiter écrivait : i still have problems with atapicam and atang, while booting with atapicam i get these messages: There is nothing abnormal with these messages. When trying to burn a disk with cdrecord i get the following panic: panic: mutex vm object not owned at /usr/src/sys/vm/vm_page.c:761 AFAIK this is irrelevant to ATAPI or ATAPI/CAM. Is this related to the above failures or some issue with cdrecord? No, this has nothing to do with the boot messages you quoted. Thomas. -- [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ATAng no good for me/REQUEST_SENSE recovered from missing interrupt
Le 2003-09-21, Dan Naumov écrivait : (probe2:ata1:0:0:0): Recovered Sense (probe2:ata1:0:0:0): INQUIRY. CDB: 12 1 80 0 ff 0 (probe2:ata1:0:0:0): CAM Status: SCSI Status Error (probe2:ata1:0:0:0): SCSI Status: Check Condition (probe2:ata1:0:0:0): ILLEGAL REQUEST asc:24,0 (probe2:ata1:0:0:0): Invalid field in CDB That's fine, it just means your drive does not provide serial number information. -- [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ATAng no good for me/REQUEST_SENSE recovered from missing interrupt
Le 2003-09-21, Bryan Liesner écrivait : The patch doesn't take care of the hang for me. Does it change anything, or do you still see the 'REQUEST_SENSE recovered from missing interrupt'? Is your source tree up-to-date? Several fixes have been committed to both the ATA and the CAM subsystems recently, that address problems uncovered by the transition to ATAng. Did anyone read _any_ of my previous posts? Certainly so, since you already received answers to some of them. If you'd like to help speed up the resolution of the problems you see, maybe you could provide a backtrace at the point where your system hangs, and a log of boot -v output, with the CAMDEBUG and CAM_DEBUG_FLAGS=CAM_DEBUG_CCB options. Thomas. -- [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ATAng no good for me/REQUEST_SENSE recovered from missing interrupt
Le 2003-09-21, Shin-ichi Yoshimoto écrivait : I could not get a backtrace because infinite loop occured like this: Can't you drop into DDB at that point? Also, do you have up-to-date sources? Thomas. -- [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ATAng no good for me/REQUEST_SENSE recovered from missing interrupt
Le 2003-09-21, Daniel Eischen écrivait : Sep 21 12:40:28 sirius kernel: (cd0:ata0:0:0:0): CAM Status: SCSI Status Error Sep 21 12:40:28 sirius kernel: (cd0:ata0:0:0:0): SCSI Status: Check Condition Sep 21 12:40:28 sirius kernel: (cd0:ata0:0:0:0): Recovered Sense Sep 21 12:40:28 sirius kernel: (cd0:ata0:0:0:0): READ CD RECORDED CAPACITY. CDB: 25 0 0 0 0 0 0 0 0 0 Sep 21 12:40:28 sirius kernel: (cd0:ata0:0:0:0): CAM Status: SCSI Status Error Um, strange, this is exactly what cam_periph.c rev. 1.53 was supposed to fix. Thomas. -- [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ATAng no good for me/REQUEST_SENSE recovered from missing interrupt
Le 2003-09-21, Bryan Liesner écrivait : Thanks, the hang problems are fixed now. That's great news! No one told me that I was barking up the wrong tree... Ah, computers are fragile and playful things that always find creative and unexcepted ways of failing... :) Thomas. -- [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ATAng no good for me/REQUEST_SENSE recovered from missing interrupt
Le 2003-09-20, Daniel Eischen écrivait :
No, using latest sources, with or without atapicam, does
not solve the problem. It still hangs.
Please try the patch below, it should at least work around the problem.
http://people.freebsd.org/~deischen/ata_hang.091903
Interesting, the last 2 lines are :
ata0: spurious interrupt - status=0x50 error=0x00
acd0: WARNING - REQUEST_SENSE recovered from missing interrupt
so I'd suspect there is some race condition between the interrupt
and the REQUEST_SENSE command. Søren, shouldn't ata_interrupt lock the
channel before copying ch-running?
Thomas.
Index: atapi-cam.c
===
RCS file: /home/ncvs/src/sys/dev/ata/atapi-cam.c,v
retrieving revision 1.23
diff -u -r1.23 atapi-cam.c
--- atapi-cam.c 19 Sep 2003 16:25:44 - 1.23
+++ atapi-cam.c 20 Sep 2003 19:29:41 -
@@ -561,6 +561,7 @@
#endif
if (hcb_status != 0) {
csio-scsi_status = SCSI_STATUS_CHECK_COND;
+#if 0
if ((csio-ccb_h.flags CAM_DIS_AUTOSENSE) == 0) {
int8_t ccb[16] = { ATAPI_REQUEST_SENSE, 0, 0, 0,
sizeof(struct atapi_sense), 0, 0, 0, 0, 0, 0,
@@ -572,6 +573,7 @@
csio-ccb_h.status |= CAM_AUTOSNS_VALID;
}
}
+#endif
free_hcb_and_ccb_done(hcb, CAM_SCSI_STATUS_ERROR);
}
else {
--
[EMAIL PROTECTED]
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ATAng no good for me
Le 2003-09-20, David R. Colyer écrivait : Is atapicam a kernel config option? It is a device (cf. man atapicam): you can enable it with device atapicam in your kernel config file. I can't seem to find it, and now since a cvsup up on the 17h, my plextor scsi cdrw locks my system and then reboots immediately after a burning program, (i've tried several) initializes the drive. It worked several weeks ago just fine. Any suggestions would be greatly appreciated. Thanks in advance. If it is an SCSI (SPI) drive, then ATAPI/CAM is irrelevant. The purpose of ATAPI/CAM is to allow access to ATAPI drives through the CAM framework. Thomas. -- [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ATAng still problematic
Le 2003-09-19, Dan Naumov écrivait : Disabling atapicam in the kernel or detaching the drive from the system works around the problem. Please try the patch I posted a few moments ago under ATAng no good for me/REQUEST_SENSE recovered from missing interrupt. Thomas. -- [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ATAng no good for me/REQUEST_SENSE recovered from missing interrupt
Le 2003-09-20, Shin-ichi Yoshimoto écrivait : acd0: WARNING - REQUEST_SENSE recovered from missing interrupt This message disappeared, but It still hang Can you get a backtrace at that point? -- [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: acd0 vs cd0 (ATAPICAM)
Le 2003-09-19, Guillaume écrivait : Thanks for the patch. cd0 is faster now and ATAPICAM works great. That's good news! Are you going to commit the patch? Yes, the patch is currently being reviewed. -- [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ATAng still problematic
Le 2003-09-18, Jan Srzednicki écrivait : Anyway, here's backtrace for atapicam panic I've mentioned. It's triggered by: cdrecord dev=1,1,0 /some/track Um. Do you see the same crash if both drives contain CDs at boot time? If not, this could be a consequence of the error condition corruption problem others have been reporting. Thomas. -- [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: acd0 vs cd0 (ATAPICAM)
Le 2003-09-17, Guillaume écrivait : + if (atapi_dma atp-channel-dma + (atp-param-config ATA_DRQ_MASK) != ATA_DRQ_INTR) + atp-setmode(atadev, ATA_DMA_MAX); + else + atp-setmode(atadev, ATA_PIO_MAX); Ahem. Replace atadev with atp on both lines... Thomas. -- [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: acd0 vs cd0 (ATAPICAM)
Le 2003-09-17, Bryan Liesner écrivait : The patch seems to work, my cd0 and cd1 lines in the dmesg now report 33.000 MB/s insetad of 3.300 MB/s. OK, good, so that's one half of the problem resolved. Now, can you test whether the actual performances are improved or still slow? Thomas. -- [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: system hang on boot w/ atapicam0: timeout waiting for ATAPI ready (5.1-CURRENT, IBM T30)
Le 2003-09-15, Lee Damon écrivait : Yesterday's cvsup'd and compiled kernel hung at acd0: CDRW UJDA720 DVD/CDRW at ata1-master UDMA33 atapicam0: timeout waiting for ATAPI ready This is from the low-level ATA layer. Do you see the same message if you disable ATAPICAM? Thomas. -- [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: scsi_cd or atapicam crash in current.
Le 2003-09-13, Daniel Eischen écrivait : cd0 at ata1 bus 0 target 0 lun 0 cd0: HL-DT-ST RW/DVD GCC-4240N D110 Removable CD-ROM SCSI-0 device cd0: 33.000MB/s transfers cd0: cd present [3737169375 x 3737169374 byte records] Several others have reported similar completely bogus sector size data. I suspect a problem in the new autosense code. It would be interesting to see what the kernel says when compiled with CAMDEBUG and running with CAM_DEBUG_CDB traces enabled (camcontrol debug -c). Thomas. -- [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: atapicam panic
Le 2003-09-06, Petri Helenius écrivait :
Should this work or is the work to port this to ATAng still undergoing?
This should work, but does not, so the work is still in progress...
panic: mutex Giant not owned at ../../../dev/ata/atapi-cam.c:117
Please try this patch.
Index: atapi-cam.c
===
RCS file: /home/ncvs/src/sys/dev/ata/atapi-cam.c,v
retrieving revision 1.22
diff -u -r1.22 atapi-cam.c
--- atapi-cam.c 11 Sep 2003 17:34:47 - 1.22
+++ atapi-cam.c 16 Sep 2003 12:51:35 -
@@ -114,13 +114,10 @@
struct cam_path *path = NULL;
int unit;
-GIANT_REQUIRED;
-
if (mtx_initialized(atapicam_softc_mtx) == 0)
mtx_init(atapicam_softc_mtx, ATAPI/CAM softc mutex, NULL, MTX_DEF);
mtx_lock(atapicam_softc_mtx);
-
LIST_FOREACH(scp, all_buses, chain) {
if (scp-ata_ch == ata_ch)
break;
@@ -130,10 +127,12 @@
if (scp != NULL)
return;
-if ((scp = malloc(sizeof(struct atapi_xpt_softc),
- M_ATACAM, M_NOWAIT | M_ZERO)) == NULL)
- goto error;
+scp = malloc(sizeof(struct atapi_xpt_softc),
+M_ATACAM, M_NOWAIT | M_ZERO));
+mtx_lock (Giant);
+if (scp == NULL)
+ goto error;
scp-ata_ch = ata_ch;
TAILQ_INIT(scp-pending_hcbs);
LIST_INSERT_HEAD(all_buses, scp, chain);
@@ -165,10 +164,12 @@
setup_async_cb(scp, AC_LOST_DEVICE);
reinit_bus(scp, cold ? BOOT_ATTACH : ATTACH);
+mtx_unlock (Giant);
return;
error:
free_softc(scp);
+mtx_unlock (Giant);
}
void
--
[EMAIL PROTECTED]
pgp0.pgp
Description: PGP signature
Re: acd0 vs cd0 (ATAPICAM)
Le 2003-09-06, Guillaume écrivait : I'm running FreeBSD 5-CURRENT (Aug. 28 2003) on a P3 733MHz, 768MB ram with a LG DVD-RW/DVD-RAM burner. I would like to know why ATAPICAM is so slow with my system. Maybe because ATAPI/CAM does not actually enable DMA. Can you try the following patch? Thomas. Index: atapi-cam.c === RCS file: /home/ncvs/src/sys/dev/ata/atapi-cam.c,v retrieving revision 1.22 diff -u -r1.22 atapi-cam.c --- atapi-cam.c 11 Sep 2003 17:34:47 - 1.22 +++ atapi-cam.c 16 Sep 2003 13:20:18 - @@ -227,6 +227,11 @@ 2 * device_get_unit(atp-channel-dev) + (atp-unit == ATA_MASTER) ? 0 : 1); atp-softc = (void *)scp; + if (atapi_dma atp-channel-dma + (atp-param-config ATA_DRQ_MASK) != ATA_DRQ_INTR) + atp-setmode(atadev, ATA_DMA_MAX); + else + atp-setmode(atadev, ATA_PIO_MAX); } } -- [EMAIL PROTECTED] pgp0.pgp Description: PGP signature
Re: scsi_cd or atapicam crash in current.
Le 2003-09-16, Daniel Eischen écrivait :
I get this even without atapicam in the kernel. Is trying
CAMDEBUG and CAM_DEBUG_CDB going to show anything interesting?
No, indeed, probably not. Can you try the following patch:
Index: ata-lowlevel.c
===
RCS file: /home/ncvs/src/sys/dev/ata/ata-lowlevel.c,v
retrieving revision 1.11
diff -u -r1.11 ata-lowlevel.c
--- ata-lowlevel.c 10 Sep 2003 09:57:16 - 1.11
+++ ata-lowlevel.c 16 Sep 2003 15:00:13 -
@@ -374,6 +374,11 @@
/* ATAPI PIO commands */
case ATA_R_ATAPI:
+ if (request-status (ATA_S_ERROR | ATA_S_DWF)) {
+ request-error = ATA_IDX_INB(ch, ATA_ERROR);
+ break;
+ }
+
length = ATA_IDX_INB(ch, ATA_CYL_LSB)|(ATA_IDX_INB(ch, ATA_CYL_MSB)8);
switch ((ATA_IDX_INB(ch, ATA_IREASON) (ATA_I_CMD | ATA_I_IN)) |
@@ -446,8 +451,6 @@
case ATAPI_P_ABORT:
case ATAPI_P_DONE:
- if (request-status (ATA_S_ERROR | ATA_S_DWF))
- request-error = ATA_IDX_INB(ch, ATA_ERROR);
break;
default:
--
[EMAIL PROTECTED]
pgp0.pgp
Description: PGP signature
Re: scsi_cd or atapicam crash in current.
Le 2003-09-12, Kevin Oberman écrivait : cdstart(c419d500,c4192000,1,c407cc30,c407cc00) at cdstart+0xcb xpt_run_dev_allocq(c40b8c00,c407cc08,1,c418d800,c419d500) at xpt_run_dev_allocq+0xab xpt_schedule(c419d500,1,0,ce54ec78,dd5b6c70) at xpt_schedule+0xca cdstrategy(ce54ec78,0,0,0,d439f000) at cdstrategy+0x88 It would be useful if you could send line number information for these addresses (under gdb, info line *cdstart+0xcb ...) Thanks, Thomas. -- [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: HEADS UP! ATAng committed
Le 2003-08-30, Glenn Johnson écrivait : I guess I wrote that too soon, it just locked up again. This time though, the machine rebooted after about 10 seconds so I could not get to another machine to see if I could poke around. If it rebooted, then maybe it panic'd. Do you have a kernel core dump? -- [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: HEADS UP! ATAng committed
Le 2003-08-29, Glenn Johnson écrivait : When I have atapicam enabled in my kernel config (-current, as of Aug 28, 2003; 11:00 PM CDT), my system locks up when trying to load nautilus. Nautilus loads fine after removing the atapicam option. Atapicam worked fine prior to ATAng. Strange. No messages on the system console? -- [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: HEADS UP! ATAng committed
Le 2003-08-29, Glenn Johnson écrivait : console. There was nothing written to the log file that I remember but I should check that again tonight when I get home. I will also try to ssh in from another machine and see if the network is still up. Yes. A serial console could also perhaps provide some messages. Thomas. -- [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: recent 5.1-CURRENT kernel panics on acd0 probe/attach, IBM T30
Le 2003-08-27, Lee Damon écrivait : Removing atapicam from my kernel configuration fixed the problem for me as well. Please try the patch I posted on -current under HEADS UP! ATAng committed. Thanks, Thomas. -- [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: HEADS UP! ATAng committed
Le 2003-08-25, Matt écrivait :
Fatal trap 12: page fault while in kernel mode
fault virtual address = 0x0
fault code = supervisor write, page not present
instruction pointer = 0x8:0xc015e59e
stack pointer = 0x10:0xd717bac0
frame pointer = 0x10:0xd717bacc
code segment = base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags = interrupt enabled, resume, IOPL = 0
current process = 18 (swi3: cambio)
kernel: type 12 trap, code=0
Stopped at free_hcb+0x2e: movl %eax,0(%edx)
OK, trivial one. Thanks to all who contributed feedback on this issue.
Thomas.
Index: atapi-cam.c
===
RCS file: /home/ncvs/src/sys/dev/ata/atapi-cam.c,v
retrieving revision 1.20
diff -u -r1.20 atapi-cam.c
--- atapi-cam.c 24 Aug 2003 17:48:05 - 1.20
+++ atapi-cam.c 27 Aug 2003 22:35:56 -
@@ -465,9 +465,10 @@
if ((ccb_h-flags CAM_DIR_MASK) == CAM_DIR_IN (len 1)) {
/* ATA always transfers an even number of bytes */
if (!(buf = hcb-dxfer_alloc = malloc(++len, M_ATACAM,
- M_NOWAIT | M_ZERO)))
+ M_NOWAIT | M_ZERO))) {
printf(cannot allocate ATAPI/CAM buffer\n);
goto action_oom;
+ }
}
request-device = dev;
request-driver = hcb;
--
[EMAIL PROTECTED]
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: HEADS UP! ATAng committed
Le 2003-08-24, Matt écrivait : This did work perfectly with the old ATA, but the new ATA panic's. I have found that it is due to having device atapicam for the SCSI emulation. If I I'll need a backtrace please. Thanks, Thomas. -- [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: HEADS UP! ATAng committed
Le 2003-08-25, Matt écrivait :
db trace
free_hcb(c40f1040,c03c7e40,101,c41d5800,c1528130) at free_hcb+0x2e
atapi_action(c40f1440,c41d5800,c0132b33,c41db000,c41d5800) at
atapi_action+ox56c
OK, so that presumably means we're going through action_oom, and so you
should have had one of the following messages on the console:
printf(cannot allocate ATAPI/CAM hcb\n);
printf(cannot allocate ATAPI/CAM request\n);
printf(cannot allocate ATAPI/CAM buffer\n);
It would be interesting to know which, if any, of these messages you
saw. Also, please try whether the following patch improves the
situation:
Index: atapi-cam.c
===
RCS file: /home/ncvs/src/sys/dev/ata/atapi-cam.c,v
retrieving revision 1.20
diff -u -r1.20 atapi-cam.c
--- atapi-cam.c 24 Aug 2003 17:48:05 - 1.20
+++ atapi-cam.c 25 Aug 2003 17:24:44 -
@@ -59,7 +59,7 @@
intlun;
union ccb *ccb;
intflags;
-#define DOING_AUTOSENSE 1
+#define QUEUED 0x0001;
char *dxfer_alloc;
TAILQ_ENTRY(atapi_hcb) chain;
@@ -394,7 +394,7 @@
/* scatter-gather not supported */
xpt_print_path(ccb_h-path);
printf(ATAPI/CAM does not support scatter-gather yet!\n);
- break;
+ goto action_invalid;
}
if ((hcb = allocate_hcb(softc, unit, bus, ccb)) == NULL) {
@@ -464,8 +464,8 @@
if ((ccb_h-flags CAM_DIR_MASK) == CAM_DIR_IN (len 1)) {
/* ATA always transfers an even number of bytes */
- if (!(buf = hcb-dxfer_alloc = malloc(++len, M_ATACAM,
- M_NOWAIT | M_ZERO)))
+ if ((buf = hcb-dxfer_alloc = malloc(++len, M_ATACAM,
+ M_NOWAIT | M_ZERO)) == NULL)
printf(cannot allocate ATAPI/CAM buffer\n);
goto action_oom;
}
@@ -494,6 +494,7 @@
}
TAILQ_INSERT_TAIL(softc-pending_hcbs, hcb, chain);
+ hcb-flags |= QUEUED;
ata_queue_request(request);
return;
@@ -519,9 +520,13 @@
return;
action_invalid:
- ccb_h-status = CAM_REQ_INVALID;
- xpt_done(ccb);
- return;
+if (request != NULL)
+ ata_free_request(request);
+if (hcb != NULL)
+ free_hcb(hcb);
+ccb_h-status = CAM_REQ_INVALID;
+xpt_done(ccb);
+return;
}
static void
@@ -686,7 +691,8 @@
static void
free_hcb(struct atapi_hcb *hcb)
{
-TAILQ_REMOVE(hcb-softc-pending_hcbs, hcb, chain);
+if ((hcb-flags QUEUED) != 0)
+TAILQ_REMOVE(hcb-softc-pending_hcbs, hcb, chain);
if (hcb-dxfer_alloc != NULL)
free(hcb-dxfer_alloc, M_ATACAM);
free(hcb, M_ATACAM);
--
[EMAIL PROTECTED]
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: crash: bwrite: need chained iodone
Le 2003-03-12, Jeff Roberson écrivait :
Can you please print bp? I'd like to know what all of the members are. A
cluster buf should NEVER have BX_BKGRDWRITE set. This is totally bogus.
Got that crash again, with sync-on-panic disabled. The interesting thing
is that the stack trace might be corrupted or inaccurate (maybe some tail
recursion optimisation or inlining is going on around): although it seems
to indicate that the panic is the one from bwrite: need chained iodone
(which is absurd, as we saw, since bp-bp_xflags == 0), the panic
message is buffer is not busy??? from bwrite, and indeed we can see
that this is the case (see print of bp-b_lock).
Thomas.
Script started on Mon Mar 17 12:06:57 2003
This is ZSH 4.0.6 on a xterm-color
([EMAIL PROTECTED]) /var/crash # gdb -k /usr/obj/usr/src/sys/MALEVIL/kernel.debug
vmcore.7
GNU gdb 5.2.1 (FreeBSD)
Copyright 2002 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type show copying to see the conditions.
There is absolutely no warranty for GDB. Type show warranty for details.
This GDB was configured as i386-undermydesk-freebsd...
panic: bwrite: buffer is not busy???
panic messages:
---
panic: bwrite: buffer is not busy???
Uptime: 3d17h25m5s
Dumping 511 MB
ata0: resetting devices ..
done
16 32 48 64 80 96 112 128 144 160 176 192 208 224 240 256 272 288 304 320 336 352 368
384 400 416 432 448 464 480 496
---
#0 doadump () at /usr/src/sys/kern/kern_shutdown.c:239
239 dumping++;
(kgdb) bt
#0 doadump () at /usr/src/sys/kern/kern_shutdown.c:239
#1 0xc01f4698 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:371
#2 0xc01f4903 in panic () at /usr/src/sys/kern/kern_shutdown.c:542
#3 0xc0232072 in bwrite (bp=0xce531228) at /usr/src/sys/kern/vfs_bio.c:795
#4 0xc0232a7c in bawrite (bp=0x0) at /usr/src/sys/kern/vfs_bio.c:1138
#5 0xc023a02b in cluster_wbuild (vp=0xc5ff8db0, size=16384, start_lbn=21,
len=4) at /usr/src/sys/kern/vfs_cluster.c:996
#6 0xc02396ff in cluster_write (bp=0xce6237a8, filesize=378368, seqcount=4)
at /usr/src/sys/kern/vfs_cluster.c:596
#7 0xc02e3fec in ffs_write (ap=0xe5d49be0)
at /usr/src/sys/ufs/ffs/ffs_vnops.c:728
#8 0xc024e1b2 in vn_write (fp=0xc5f56618, uio=0xe5d49c7c,
active_cred=0xc5f91480, flags=0, td=0xc4170a50) at vnode_if.h:417
#9 0xc0214008 in dofilewrite (td=0xc4170a50, fp=0xc5f56618, fd=0,
buf=0x8c1a400, nbyte=0, offset=0, flags=0) at file.h:239
#10 0xc0213e49 in write (td=0xc4170a50, uap=0xe5d49d10)
at /usr/src/sys/kern/sys_generic.c:329
#11 0xc033a68e in syscall (frame=
{tf_fs = 47, tf_es = 148963375, tf_ds = -1078001617, tf_edi = 677204256, tf_esi
= 0, tf_ebp = -1077939928, tf_isp = -439050892, tf_ebx = 677216484, tf_edx = 20,
tf_ecx = 0, tf_eax = 4, tf_trapno = 0, tf_err = 2, tf_eip = 677548851, tf_cs = 31,
tf_eflags = 518, tf_esp = -1077939988, tf_ss = 47})
at /usr/src/sys/i386/i386/trap.c:1030
#12 0xc032a89d in Xint0x80_syscall () at {standard input}:138
---Can't read userspace from dump, or kernel process---
(kgdb) fr 3
#3 0xc0232072 in bwrite (bp=0xce531228) at /usr/src/sys/kern/vfs_bio.c:795
795 panic(bwrite: need chained iodone);
(kgdb) list
790 (bp-b_flags B_ASYNC)
791 !vm_page_count_severe()
792 !buf_dirty_count_severe()) {
793 if (bp-b_iodone != NULL) {
794 printf(bp-b_iodone = %p\n, bp-b_iodone);
795 panic(bwrite: need chained iodone);
796 }
797
798 /* get a new block */
799 newbp = geteblk(bp-b_bufsize);
(kgdb) print *bp
$1 = {b_io = {bio_cmd = 1, bio_dev = 0x, bio_disk = 0x0,
bio_blkno = 18520608, bio_offset = 926699520, bio_bcount = 32768,
bio_data = 0xd42ba000 , bio_flags = 0, bio_error = 0, bio_resid = 0,
bio_done = 0xc0235db0 bufdonebio, bio_driver1 = 0x0, bio_driver2 = 0x0,
bio_caller1 = 0x0, bio_caller2 = 0xce531228, bio_queue = {tqe_next = 0x0,
tqe_prev = 0x0}, bio_attribute = 0x0, bio_from = 0x0, bio_to = 0x0,
bio_length = 0, bio_completed = 0, bio_children = 259, bio_inbed = 0,
bio_parent = 0x0, bio_t0 = {sec = 0, frac = 0}, bio_task = 0,
bio_task_arg = 0x0, bio_pblkno = 0}, b_op = 0xc03a89f8,
b_magic = 280038160, b_iodone = 0xc0239320 cluster_callback,
b_offset = 311296, b_vnbufs = {tqe_next = 0x0, tqe_prev = 0x0},
b_left = 0x0, b_right = 0x0, b_vflags = 0, b_freelist = {
tqe_next = 0xce531fe8, tqe_prev = 0xc03dcb3c}, b_qindex = 0,
b_flags = 1677721604, b_xflags = 0 '\0', b_lock = {
lk_interlock = 0xc03d74d8, lk_flags = 0, lk_sharecount = 0,
lk_waitcount = 0, lk_exclusivecount = 0, lk_prio = 80,
lk_wmesg = 0xc0379b53 bufwait, lk_timo = 0, lk_lockholder = 0x,
lk_newlock = 0x0},
Re: crash: bwrite: need chained iodone
Le 2003-03-12, Jeff Roberson écrivait : Can you disable sync on panic to make sure that something has not come along and cleaned this buffer? I suspect that it has been modified after the first panic. Do you know when this first started to happen? Do you have any more clues into what triggered it? I have now disabled sync_on_panic for future crashes :) I did not see this crash before I upgraded from 5.0-REL to -CURRENT last weekend (I previously had panics consecutive to vm_page_wakeup being called with a NULL argument, which is why I upgraded). I have little idea as to what exactly might have caused the crash. I was using the machine for desktop work (a few rxvts, xemacs, xchat, so on, with the Nvidia driver with Maxime's patches). Thomas. -- [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: crash: bwrite: need chained iodone
Le 2003-03-12, Jeff Roberson écrivait :
Can you please print bp? I'd like to know what all of the members are. A
cluster buf should NEVER have BX_BKGRDWRITE set. This is totally bogus.
(kgdb) fr
#11 0xc0232072 in bwrite (bp=0xce5313e0) at
/usr/src/sys/kern/vfs_bio.c:795
795 panic(bwrite: need chained iodone);
(kgdb) print *bp
$3 = {b_io = {bio_cmd = 2, bio_dev = 0x, bio_disk = 0x0,
bio_blkno = 18540672, bio_offset = 9492758528, bio_bcount = 32768,
bio_data = 0xd42da000 , bio_flags = 0, bio_error = 0, bio_resid = 0,
bio_done = 0xc0235db0 bufdonebio, bio_driver1 = 0x0, bio_driver2 = 0x0,
bio_caller1 = 0x0, bio_caller2 = 0xce5313e0, bio_queue = {tqe_next = 0x0,
tqe_prev = 0xc408200c}, bio_attribute = 0x0, bio_from = 0x0,
bio_to = 0x0, bio_length = 0, bio_completed = 0, bio_children = 91,
bio_inbed = 0, bio_parent = 0x0, bio_t0 = {sec = 0, frac = 0},
bio_task = 0, bio_task_arg = 0x0, bio_pblkno = 64}, b_op = 0xc03a89f8,
b_magic = 280038160, b_iodone = 0xc0239320 cluster_callback,
b_offset = 688128, b_vnbufs = {tqe_next = 0x0, tqe_prev = 0x0},
b_left = 0x0, b_right = 0x0, b_vflags = 0, b_freelist = {
tqe_next = 0xce531228, tqe_prev = 0xc03dcb3c}, b_qindex = 0,
b_flags = 1677721604, b_xflags = 0 '\0', b_lock = {
lk_interlock = 0xc03d750c, lk_flags = 0, lk_sharecount = 0,
lk_waitcount = 0, lk_exclusivecount = 0, lk_prio = 80,
lk_wmesg = 0xc0379b53 bufwait, lk_timo = 0, lk_lockholder = 0x,
lk_newlock = 0x0}, b_bufsize = 32768, b_runningbufspace = 0,
b_kvabase = 0xd42da000 , b_kvasize = 32768, b_lblkno = 42,
b_vp = 0xc4a21124, b_object = 0x0, b_dirtyoff = 0, b_dirtyend = 32768,
b_rcred = 0x0, b_wcred = 0x0, b_saveaddr = 0xbfbfea40, b_pager = {
pg_spc = 0x0, pg_reqpage = 0}, b_cluster = {cluster_head = {
tqh_first = 0xce67bfe8, tqh_last = 0xce6b6b80}, cluster_entry = {
tqe_next = 0xce67bfe8, tqe_prev = 0xce6b6b80}}, b_pages = {0xc0d14748,
0xc0acff90, 0xc0a7cbd8, 0xc0bffc20, 0xc1074868, 0xc10106b0, 0xc10700f8,
0xc0f9c040, 0xc0af5808, 0xc0c56c50, 0xc0b47198, 0xc0bdb9e0, 0xc10e7b28,
0xc0abba70, 0xc09888b8, 0xc09d3600, 0xc0d14748, 0xc0acff90, 0xc0a7cbd8,
0xc0bffc20, 0xc1074868, 0xc10106b0, 0xc10700f8, 0xc0f9c040, 0xc0d21888,
0xc105cfd0, 0xc1057f18, 0xc109ff60, 0xc0a18948, 0xc0ab3d90, 0xc0a36fd8,
0xc0b91820}, b_npages = 8, b_dep = {lh_first = 0x0}}
(kgdb)
Hum. Now this is *most* peculiar. bp-b_xflags is 0, so we should never
have entered that 'if', unless there is a race condition somewhere such
that we test b_xflags on a buffer and carry on processing on another...
Hope this helps...
Thomas.
--
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
crash: bwrite: need chained iodone
-CURRENT as of this week-end on a Dell Inspiron 8200 laptop.
During desktop use :
panic: bremfree: removing a buffer not on a queue
panic messages:
---
panic: bwrite: buffer is not busy???
syncing disks, buffers remaining... panic: bremfree: removing a buffer not on a queue
Uptime: 9h18m39s
Dumping 511 MB
ata0: resetting devices ..
done
16[CTRL-C to abort] [CTRL-C to abort] [CTRL-C to abort] [CTRL-C to abort] [CTRL-C to
abort] [CTRL-C to abort] 32 48 64 80 96 112 128 144 160 176 192 208 224 240 256 272
288 304 320 336 352 368 384 400 416 432 448 464 480 496
---
#0 doadump () at /usr/src/sys/kern/kern_shutdown.c:239
239 dumping++;
(kgdb) bt
#0 doadump () at /usr/src/sys/kern/kern_shutdown.c:239
#1 0xc01f4698 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:371
#2 0xc01f4903 in panic () at /usr/src/sys/kern/kern_shutdown.c:542
#3 0xc0231bf0 in bremfreel (bp=0xce6bd4e8) at /usr/src/sys/kern/vfs_bio.c:630
#4 0xc0231b25 in bremfree (bp=0x0) at /usr/src/sys/kern/vfs_bio.c:612
#5 0xc0233db3 in vfs_bio_awrite (bp=0x0) at /usr/src/sys/kern/vfs_bio.c:1682
#6 0xc02e346a in ffs_fsync (ap=0xe5db4910)
at /usr/src/sys/ufs/ffs/ffs_vnops.c:257
#7 0xc02e263e in ffs_sync (mp=0xc4152600, waitfor=2, cred=0xc1509f00,
td=0xc039f1a0) at vnode_if.h:612
#8 0xc024649b in sync (td=0xc039f1a0, uap=0x0)
at /usr/src/sys/kern/vfs_syscalls.c:138
#9 0xc01f42ec in boot (howto=256) at /usr/src/sys/kern/kern_shutdown.c:280
#10 0xc01f4903 in panic () at /usr/src/sys/kern/kern_shutdown.c:542
#11 0xc0232072 in bwrite (bp=0xce5313e0) at /usr/src/sys/kern/vfs_bio.c:795
#12 0xc0232a7c in bawrite (bp=0x0) at /usr/src/sys/kern/vfs_bio.c:1138
#13 0xc023a02b in cluster_wbuild (vp=0xc4a21124, size=16384, start_lbn=44,
len=3) at /usr/src/sys/kern/vfs_cluster.c:996
#14 0xc02396ff in cluster_write (bp=0xce6bd4e8, filesize=753664, seqcount=18)
at /usr/src/sys/kern/vfs_cluster.c:596
#15 0xc02e3fec in ffs_write (ap=0xe5db4be0)
at /usr/src/sys/ufs/ffs/ffs_vnops.c:728
#16 0xc024e1b2 in vn_write (fp=0xc456921c, uio=0xe5db4c7c,
---Type return to continue, or q return to quit---
active_cred=0xc48e5780, flags=0, td=0xc46e2000) at vnode_if.h:417
#17 0xc0214008 in dofilewrite (td=0xc46e2000, fp=0xc456921c, fd=0,
buf=0x8e1e400, nbyte=0, offset=0, flags=0) at file.h:239
#18 0xc0213e49 in write (td=0xc46e2000, uap=0xe5db4d10)
at /usr/src/sys/kern/sys_generic.c:329
#19 0xc033a68e in syscall (frame=
{tf_fs = 47, tf_es = 47, tf_ds = 134742063, tf_edi = 677204256, tf_esi = 0,
tf_ebp = -1077939928, tf_isp = -438612620, tf_ebx = 677216484, tf_edx = 20, tf_ecx =
0, tf_eax = 4, tf_trapno = 0, tf_err = 2, tf_eip = 677548851, tf_cs = 31, tf_eflags =
518, tf_esp = -1077939988, tf_ss = 47})
at /usr/src/sys/i386/i386/trap.c:1030
#20 0xc032a89d in Xint0x80_syscall () at {standard input}:138
---Can't read userspace from dump, or kernel process---
(kgdb) fr 3
#3 0xc0231bf0 in bremfreel (bp=0xce6bd4e8) at /usr/src/sys/kern/vfs_bio.c:630
630 panic(bremfree: removing a buffer not on a queue);
(kgdb) fr 11
#11 0xc0232072 in bwrite (bp=0xce5313e0) at /usr/src/sys/kern/vfs_bio.c:795
795 panic(bwrite: need chained iodone);
(kgdb) list
790 (bp-b_flags B_ASYNC)
791 !vm_page_count_severe()
792 !buf_dirty_count_severe()) {
793 if (bp-b_iodone != NULL) {
794 printf(bp-b_iodone = %p\n, bp-b_iodone);
795 panic(bwrite: need chained iodone);
796 }
797
798 /* get a new block */
799 newbp = geteblk(bp-b_bufsize);
(kgdb) print bp-b_iodone
$1 = (void (*)(struct buf *)) 0xc0239320 cluster_callback
(kgdb) quit
I still have the crash dump at hand, if further forensics is necessary.
--
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: Panic: vm_page_wakeup(NULL)
Le 2003-02-05, Thomas Quinot écrivait :
#13 0xc032f438 in calltrap () at {standard input}:98
#14 0xc030652c in vm_page_wakeup (m=0x0) at /usr/src/sys/vm/vm_page.c:324
Got the same one again last night circa 04:30, while the machine was
completely idle (except for an xscreensaver process drawing nice stuff
on the screen.)
Thomas.
--
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: Local repo: Perforce/CVS integration
Le 2003-02-16, Chris BeHanna écrivait : Do you use cvs2p4? How about going in the other direction (from your local branches back to the trunk?) VCP is also a nice solution for moving changes across CVS and Perforce repositories. I use it to update a read-only CVS pserver view of a project that is developed using Perforce (http://libre.act-europe.fr/polyorb, for those interested :) ). Info on VCP can be found at http://aspn.activestate.com/ASPN/CodeDoc/VCP/VCP/Source/revml.html Thomas. -- [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: call for testers: cd(4) changes
Le 2003-02-15, Kenneth D. Merry écrivait :
- Automatically detect CDROM drives that can't handle 6 byte mode
sense and mode select, and adjust our command size accordingly.
More information on that below.
- MODE_SENSE and MODE_SELECT translation removed in ATAPICAM and in
the umass(4) driver, since there's no way for that to work properly
(see below).
I'm afraid things are not as simple as that. Unfortunately you cannot
expect ATAPI drives to properly reject MODE_{SENSE,SELECT}_6 and try the
_10 variants in that case: the reason why ATAPICAM inconditionnally
translates the _6 commands into _10 is because some ATAPI drives have
been found to lock up when they rececive the _6 commands, whereas the
ATAPI specification only mandates the implementation of the _10
versions.
- The media validation routine also reads the table of contents off
the drive.
Great! That could also allow the creation of per-track /dev nodes, as
acd has.
Thomas.
--
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: 5.0 cron problem
Le 2003-02-08, CHOI Junho écrivait : Oh sorry... I didn't restart cron :P. It works well. 'cron -x pars' says that whitespaces is correctly parsed. OK, that's reassuring! Ollivier can you review the posted patch please? Thanks, Thomas. -- [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Corrupted crashdump?
On a Dell Inspiron 8200 laptop, with ACPI disabled, 5.0-REL rebooted while the system was quiescent. gdb appears to be unable to make sense of the produced crash dump: # gdb -k /usr/obj/usr/src/sys/MALEVIL/kernel.debug vmcore.1 GNU gdb 5.2.1 (FreeBSD) [...] This GDB was configured as i386-undermydesk-freebsd... can not access 0xc03a4a2c, invalid address (c03a4a2c) can not access 0xc03a4a2c, invalid address (c03a4a2c) panic messages: --- dmesg: kvm_read: invalid address (c03bf6bc) --- can not access 0xc03d6d40, invalid address (c03d6d40) can not access 0xc03d6d40, invalid address (c03d6d40) #0 0x in ?? () (kgdb) bt #0 0x in ?? () (kgdb) Thomas. -- [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: 5.0 cron problem
Le 2003-02-05, Tim Robbins écrivait :
Since revision 1.11 of src/usr.sbin/cron/lib/env.c, you need to put the
value of the environment variable inside quotes if it contains any spaces.
I suspect that this change of behaviour was unintentional given that the
implementation differs from the manual page. I'll investigate and fix
it if it's a bug. In the mean time, use something like this instead:
CVSUP=/usr/local/bin/cvsup -g -L2 -h localhost
Right, the according to the man page inner whitespace in the unquoted
right-hand part of an environment variable assignment should be preserved.
Please try the following patch:
Index: lib/env.c
===
RCS file: /home/ncvs/src/usr.sbin/cron/lib/env.c,v
retrieving revision 1.11
diff -u -r1.11 env.c
--- lib/env.c 23 May 2002 13:16:30 - 1.11
+++ lib/env.c 7 Feb 2003 10:34:48 -
@@ -193,14 +193,16 @@
break;
}
} else {
- if (isspace (*c)) {
- state++;
- c++;
- break;
- }
- if (state == NAME *c == '=') {
- state++;
- break;
+ if (state == NAME) {
+ if (isspace (*c)) {
+ c++;
+ state++;
+ break;
+ }
+ if (*c == '=') {
+ state++;
+ break;
+ }
}
}
*str++ = *c++;
@@ -232,9 +234,14 @@
Set_LineNum(fileline);
return (FALSE);
}
+ if (state == VALUE) {
+ /* End of unquoted value: trim trailing whitespace */
+ c = val + strlen (val);
+ while (c val isspace (*(c - 1)))
+ *(--c) = '\0';
+ }
- /* 2 fields from parser; looks like an env setting
-*/
+ /* 2 fields from parser; looks like an env setting */
if (strlen(name) + 1 + strlen(val) = MAX_ENVSTR-1)
return (FALSE);
--
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: 5.0 cron problem
Le 2003-02-07, CHOI Junho écrivait : Oops. It doesn't solve the problem. There is no error when editing crontab, but the variable is not substituted correctly(just blank). Hum, strange, it seemed to work here. Can you send me your crontab and the output of 'cron -x pars' ? Thomas. -- [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Panic: vm_page_wakeup(NULL)
Looks like the stack got horribly corrupted... Bonus points for double
panic while dumping.
This is 5.0-RELEASE running on a Dell Inspiron 8200 laptop with ACPI
disabled (it crashes once or twice per day when ACPI is enabled).
Fatal trap 12: page fault while in kernel mode
fault virtual address = 0x36
fault code = supervisor read, page not present
instruction pointer = 0x8:0xc030649c
stack pointer = 0x10:0xe5d8b658
frame pointer = 0x10:0xe5d8b658
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags= interrupt enabled, resume, IOPL = 0
current process = 29732 (flipscreen3d)
trap number = 12
panic: page fault
syncing disks, buffers remaining... panic: bdwrite: buffer is not busy
Uptime: 4d10h35m9s
Dumping 511 MB
ata0: resetting devices ..
done
16 32 48 64 80 96 112 128 144 160 176 192 208 224 240 256 272 288 304 320 336 352 368
384 400 416 432 448 464 480 496
---
#0 doadump () at /usr/src/sys/kern/kern_shutdown.c:232
232 dumping++;
(kgdb) bt
#0 doadump () at /usr/src/sys/kern/kern_shutdown.c:232
#1 0xc01f7f06 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:364
#2 0xc01f8153 in panic () at /usr/src/sys/kern/kern_shutdown.c:517
#3 0xc0236cbd in bdwrite (bp=0xce69e7f8) at /usr/src/sys/kern/vfs_bio.c:950
#4 0xc02d5b4b in ffs_update (vp=0xc41a87c4, waitfor=0)
at /usr/src/sys/ufs/ffs/ffs_inode.c:125
#5 0xc02e9d0f in ffs_fsync (ap=0xe5d8b48c)
at /usr/src/sys/ufs/ffs/ffs_vnops.c:315
#6 0xc02e8e1e in ffs_sync (mp=0xc415f600, waitfor=2, cred=0xc1509f00,
td=0xc039faa0) at vnode_if.h:612
#7 0xc024993b in sync (td=0xc039faa0, uap=0x0)
at /usr/src/sys/kern/vfs_syscalls.c:138
#8 0xc01f7b7c in boot (howto=256) at /usr/src/sys/kern/kern_shutdown.c:273
#9 0xc01f8153 in panic () at /usr/src/sys/kern/kern_shutdown.c:517
#10 0xc033ec42 in trap_fatal (frame=0xe5d8b618, eva=0)
at /usr/src/sys/i386/i386/trap.c:844
#11 0xc033e922 in trap_pfault (frame=0xe5d8b618, usermode=0, eva=54)
at /usr/src/sys/i386/i386/trap.c:758
#12 0xc033e4bd in trap (frame=
{tf_fs = 24, tf_es = 16, tf_ds = -438829040, tf_edi = -978624408, tf_esi = -1,
tf_ebp = -438782376, tf_isp = -438782396, tf_ebx = 0, tf_edx = -2, tf_ecx = 0, tf_eax
= 0, tf_trapno = 12, tf_err = 0, tf_eip = -1070570340, tf_cs = 8, tf_eflags = 66182,
tf_esp = -438782356, tf_ss = -1070570196})
at /usr/src/sys/i386/i386/trap.c:445
#13 0xc032f438 in calltrap () at {standard input}:98
#14 0xc030652c in vm_page_wakeup (m=0x0) at /usr/src/sys/vm/vm_page.c:324
#15 0xc058142f in ?? ()
#16 0xc05815b5 in ?? ()
#17 0xc04b6bff in ?? ()
#18 0xc04ac34c in ?? ()
#19 0xc04ac144 in ?? ()
#20 0xc04b937b in ?? ()
#21 0xc04b8e2b in ?? ()
#22 0xc0580bbf in ?? ()
#23 0xc057f1f7 in ?? ()
#24 0xc01c3cec in spec_ioctl (ap=0x)
at /usr/src/sys/fs/specfs/spec_vnops.c:352
#25 0xc01c35c8 in spec_vnoperate (ap=0x0)
at /usr/src/sys/fs/specfs/spec_vnops.c:126
#26 0xc0251b51 in vn_ioctl (fp=0xc48ccb7c, com=3223864871, data=0xe5d8bc54,
active_cred=0xc45dd680, td=0xc44e3e00) at vnode_if.h:488
#27 0xc0218e79 in ioctl (td=0xc44e3e00, uap=0xe5d8bd10) at file.h:227
#28 0xc033ef0e in syscall (frame=
{tf_fs = 47, tf_es = 47, tf_ds = 47, tf_edi = 11, tf_esi = 0, tf_ebp =
-1077939992, tf_isp = -438780556, tf_ebx = 672484484, tf_edx = 11, tf_ecx = 22372351,
tf_eax = 54, tf_trapno = 12, tf_err = 2, tf_eip = 674342131, tf_cs = 31, tf_e---Type
return to continue, or q return to quit---
flags = 534, tf_esp = -1077940036, tf_ss = 47})
at /usr/src/sys/i386/i386/trap.c:1033
#29 0xc032f48d in Xint0x80_syscall () at {standard input}:140
---Can't read userspace from dump, or kernel process---
(kgdb) fr 14
#14 0xc030652c in vm_page_wakeup (m=0x0) at /usr/src/sys/vm/vm_page.c:324
324 vm_page_flag_clear(m, PG_BUSY);
(kgdb) up
#15 0xc058142f in ?? ()
--
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: burncd/cdcontrol
Le 2002-10-27, Soeren Schmidt écrivait : Hmm, it is true that I could use ATAPI command directly in burncd, and I actually have a version in the lab that is ~75% converted to that, Nice! but that is not the only issue here. The ATAPI cd driver has quite a bit of functionality that the SCSI cd driver hasn't, fx the ability I plan to work on these. Thomas. -- [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Code factoring in /etc/periodic/security firewall checks
Le 2002-09-18, Thomas Quinot écrivait : http://www.cuivre.fr.eu.org/~thomas/periodic-fw.diff I have prepared an updated version of the patch that also includes 100.chksetuid, 200.chkmounts and 700.kernelmsg in the factoring. http://www.cuivre.fr.eu.org/~thomas/periodic-security/ -- [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Code factoring in /etc/periodic/security firewall checks
Being a user of ipfilter, I always longed for it to benefit from the same treatment as ipfw in daily security checks, so I undertook the implementation of an ipf equivalent of 500.ipfwdenied. In the course of that, I noticed that much of that script was non-trivial *and* duplicated wrt 600.ip6fwdenied *and* would be duplicated in my own ipfdenied script. Consequently, I would like to propose that most of the complexity of these scripts be factored out into a common file, which could then also be harnessed for ipfilter. And since after moaning for a change I'd be expected to put my code where my mouth is, a patch against -CURRENT is available for your perusal and comments from: http://www.cuivre.fr.eu.org/~thomas/periodic-fw.diff Thomas. -- [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: perl busted, spins, ignores SIGKILL
Le 2002-09-03, Lamont Granquist écrivait : i cvsup'd last night, and now i tried portupdate -a -f and debugging build problems with libtool i found that on my system i can make perl spin and consume 100% of a CPU just by: perl -pe s/foo/bar/g /tmp Any chance you have a /usr/local/bin/perl pointing back to /usr/bin/perl? Cf. PR bin/42418. -- [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: i386 tinderbox failure
Le 2002-09-01, Scott Long écrivait : === aic7xxx/ahc (null): Unable to malloc scope object *** Error code 70 Um, what? I just did a buildworld, followed by a buildkernel KERNCONF=GENERIC and did not see this. Um, I see this one as well, on a not-too-recent -CURRENT that I'm trying to bring up to date: FreeBSD shalmaneser.enst.fr 5.0-CURRENT FreeBSD 5.0-CURRENT #15: Mon Apr 22 17:40:12 CEST 2002 The machine is otherwise essentially idle, and top shows plenty of available memory. Thomas. -- [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Proliferating quirk table entries
Le 2002-08-17, Nate Lawson écrivait :
I'm working on cleaning up quirk entries in scsi_da.c, especially ones
related to READ/WRITE 6-10 escalation. For those just joining in, there
is a function (cmd6workaround) that handles a R/W6 error by translating
the cdb to 10 bytes and restarting it.
It might be worthwhile moving this to some generic part in the CAM
framework, instead of having it in the da driver. Similar promotion
is performed for some commands (MODE_{SELECT,SENSE}_6 as well as
{READ,WRITE}_6) in a rather ad hoc fashion in atapi-cam. At least
the cmd6workaround function should be factored in some way; as for the
try 6 - fail - retry 10 process, however, I am not sure this can
be readily generalised to ATAPI devices (which are explicitly specified
to only support the _10 variants) as these tend to have very strange
reactions to CDBs they cannot handle properly.
Thomas.
--
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: Looking for comments on a new utility...
Le 2002-06-11, Juli Mallett écrivait :
feature I've missed having in our ps(1) for a while, the ability to get a
tree of processes printed so you can tell who is whose child, etc.
Yes, this would be an invaluable feature!
Even nicer would be a user interface (command line, output style)
consistent with the existing Linux pstree utility. This one also has
a nice functionality: by default it will collapse all siblings with
the same name, in order to limit display clutter, eg:
|-omniNames---omniNames---3*[omniNames]
with the following being printed if you ask for pids ('-p'):
|-omniNames(313)---omniNames(335)-+-omniNames(336)
| |-omniNames(338)
| `-omniNames(345)
(note: this is not the same as our sysutils/pstree port, which
postprocesses the output of ps(1)).
One version of the Linux pstree is available from the psmisc port.
Another, more recent, has been ported to several platforms (including
NetBSD), see http://www.chiark.greenend.org.uk/~bjharris/.
Thomas.
--
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: Looking for comments on a new utility...
Le 2002-06-11, Juli Mallett écrivait : mask it behind something that looks good. What exactly can you get from that kind of output? The overall organization of the tree. Useless if the information you are looking for is 'what is the PID of the father of X', but may be useful when you have some complex activity going on and want to grasp the overall structure of running processes. Thomas. -- [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Two VM related crashes with yesterday's -CURRENT
Two panic's in a row, on a desktop workstation, with -CURRENT
kernel and world as of Apr. 15.
I am keeping the cores for now, if any further forensics are desired.
Thomas.
# gdb -k /usr/obj/usr/src/sys/SHALMANESER/kernel.debug
3dc44d47eaf2fa5efca6d587da113787.core
GNU gdb 4.18
Copyright 1998 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type show copying to see the conditions.
There is absolutely no warranty for GDB. Type show warranty for details.
This GDB was configured as i386-unknown-freebsd...
IdlePTD at phsyical address 0x0049f000
initial pcb at physical address 0x00398440
panicstr: bwrite: buffer is not busy???
panic messages:
---
Fatal trap 12: page fault while in kernel mode
fault virtual address = 0x11
fault code = supervisor read, page not present
instruction pointer = 0x8:0xc01d5154
stack pointer = 0x10:0xc90338cc
frame pointer = 0x10:0xc90338d8
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags= interrupt enabled, resume, IOPL = 0
current process = 605 (fsck_ufs)
trap number = 12
panic: page fault
syncing disks... panic: bwrite: buffer is not busy???
Uptime: 5m22s
Dumping 127 MB
ata0: resetting devices .. done
16 32 48 64 80 96 112
---
#0 doadump () at /usr/src/sys/kern/kern_shutdown.c:213
213 dumping++;
(kgdb) bt
#0 doadump () at /usr/src/sys/kern/kern_shutdown.c:213
#1 0xc01df201 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:346
#2 0xc01df39d in panic (fmt=0xc031942b bwrite: buffer is not busy???)
at /usr/src/sys/kern/kern_shutdown.c:490
#3 0xc0212d8d in bwrite (bp=0xc3bf3df8) at /usr/src/sys/kern/vfs_bio.c:747
#4 0xc021337e in bawrite (bp=0xc3bf3df8) at /usr/src/sys/kern/vfs_bio.c:1063
#5 0xc0297b3d in ffs_fsync (ap=0xc9033780)
at /usr/src/sys/ufs/ffs/ffs_vnops.c:209
#6 0xc029620a in ffs_sync (mp=0xc8611c00, waitfor=2, cred=0xc3b6c900,
td=0xc03616a0) at vnode_if.h:441
#7 0xc0221828 in sync (td=0xc03616a0, uap=0x0)
at /usr/src/sys/kern/vfs_syscalls.c:1217
#8 0xc01dee03 in boot (howto=256) at /usr/src/sys/kern/kern_shutdown.c:254
#9 0xc01df39d in panic (fmt=0xc0331e7e %s)
at /usr/src/sys/kern/kern_shutdown.c:490
#10 0xc02dfbc3 in trap_fatal (frame=0xc903388c, eva=17)
at /usr/src/sys/i386/i386/trap.c:841
#11 0xc02df90d in trap_pfault (frame=0xc903388c, usermode=0, eva=17)
at /usr/src/sys/i386/i386/trap.c:755
#12 0xc02df387 in trap (frame={tf_fs = -926547944, tf_es = 16, tf_ds = 16,
tf_edi = -926996512, tf_esi = -1070188480, tf_ebp = -922535720,
tf_isp = -922535752, tf_ebx = 0, tf_edx = 3058, tf_ecx = -926998528,
tf_eax = 1, tf_trapno = 12, tf_err = 0, tf_eip = -1071820460, tf_cs = 8,
tf_eflags = 66050, tf_esp = 0, tf_ss = -1011252296})
---Type return to continue, or q return to quit---
at /usr/src/sys/i386/i386/trap.c:426
#13 0xc01d5154 in free (addr=0xc8bf27e0, type=0xc0363840)
at /usr/src/sys/vm/uma_int.h:326
#14 0xc028d235 in indiracct (snapvp=0xc8c6fe10, cancelvp=0xc8c6fe10, level=0,
blkno=414, lbn=-12, rlbn=12, remblks=63988, blksperindir=1, fs=0xc4237000,
acctfunc=0xc028d390 mapacct, expungetype=2)
at /usr/src/sys/ufs/ffs/ffs_snapshot.c:752
#15 0xc028ce9d in expunge (snapvp=0xc8c6fe10, cancelip=0xc9062d00,
fs=0xc4237000, acctfunc=0xc028d390 mapacct, expungetype=2)
at /usr/src/sys/ufs/ffs/ffs_snapshot.c:636
#16 0xc028c798 in ffs_snapshot (mp=0xc8611600,
snapfile=0x80b0460 /var/.fsck_snapshot)
at /usr/src/sys/ufs/ffs/ffs_snapshot.c:469
#17 0xc0294bcc in ffs_mount (mp=0xc8611600, path=0xc8fea900 /var,
data=0xbfbffccc `\004\013\b9m\005\bØ\b\013\b\035, ndp=0xc9033c18,
td=0xc902e100) at /usr/src/sys/ufs/ffs/ffs_vfsops.c:289
#18 0xc0220df9 in vfs_mount (td=0xc902e100, fstype=0xc85a33c0 ffs,
fspath=0xc8fea900 /var, fsflags=268435456, fsdata=0xbfbffccc)
at /usr/src/sys/kern/vfs_syscalls.c:916
#19 0xc02206e6 in mount (td=0xc902e100, uap=0xc9033d20)
at /usr/src/sys/kern/vfs_syscalls.c:681
#20 0xc02dfe84 in syscall (frame={tf_fs = 47, tf_es = 47, tf_ds = 47,
tf_edi = 134955942, tf_esi = -1077936948, tf_ebp = -1077936836,
tf_isp = -922534540, tf_ebx = 134955852, tf_edx = 134955776,
---Type return to continue, or q return to quit---
tf_ecx = -1077937272, tf_eax = 21, tf_trapno = 12, tf_err = 2,
tf_eip = 134558071, tf_cs = 31, tf_eflags = 518, tf_esp = -1077937120,
tf_ss = 47}) at /usr/src/sys/i386/i386/trap.c:1037
#21 0xc02d27bd in syscall_with_err_pushed ()
#22 0x804c2fd in ?? ()
#23 0x8048137 in ?? ()
(kgdb) fr 13
#13 0xc01d5154 in free (addr=0xc8bf27e0, type=0xc0363840)
at /usr/src/sys/vm/uma_int.h:326
326 SLIST_FOREACH(slab, hash-uh_slab_hash[hval], us_hlink) {
(kgdb) print slab
$1 = 0x0
(kgdb) print
Re: This mornings world broken in libpam modules.
Le 2002-04-15, Edwin Culp écrivait : This could already be fixed but if not, mine broke at: It is fixed in Makefile.inc1 rev. 1.256. -- [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Updating from 4.4
Le 2002-04-05, Seth Hettich écrivait : Doing a buildworld I get: /usr/src/gnu/usr.bin/cc/cc_fbsd/../../../../lib/libc/stdio/mktemp.c:38: syntax error before string constant Got hit by that one two days ago. There is a patch in PR bin/36747. Thomas. -- [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: cdefs and XFree86
Le 2002-04-04, Paul Richards écrivait : #if _XOPEN_SOURCE = 600 Could be changed to #if (_XOPEN_SOURCE - 0) = 600 -- [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Problem with ssh
Le 2002-03-29, Will Andrews écrivait : SSH should just be fixed to DTRT when one doesn't have S/Key setup on the server... As far as I can understand the sources, this has been implemented in rev. 1.10 of src/crypto/openssh/auth-skey.c. Thomas. -- [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Another possible solution for non-sendmail users
Le 2002-03-28, Gregory Neil Shapiro écrivait : Opinions? Hum. If we make the assumption that non-Sendmail-users use some other MTA installed through a port or locally, then I guess that MTA should be expected to be started from a /usr/local/etc/rc.d script, so maybe the new variable mta_startup_script is overkill. On the other hand, the principle of NO_SENDMAIL in mail.conf implying no rc.sendmail installed and therefore no Sendmail daemon started looks attractive. One thing or the other, it would be nice to have that coordinated with the maintainers of the various MTA ports: qmail:MAINTAINER= [EMAIL PROTECTED] zmailer:MAINTAINER= [EMAIL PROTECTED] exim:MAINTAINER=[EMAIL PROTECTED] postfix:MAINTAINER= [EMAIL PROTECTED] ... Thomas. -- [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Rev. 1.82 of kern_linker.c disables module loads...
Le 2002-03-21, Harti Brandt écrivait : This revision of kern_linker.c entirly disables module loads from /etc/rc during boot: Or even after boot. Confirmed here: kldload always returns 'Operation not permitted'. Thomas. -- [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: cdrecord for ATAPI burners available..
Le 2002-03-20, Søren Schmidt écrivait : I thought there was work on this already ? Justin called for a timeout to get it done the right way in CAM, I was sort of expecting to hear about how that should integrate in the ATA/ATAPI world... Well I have not heard of any specific requirements on that matter. However, I will maintain the ATA/ATAPI only cd/fd/tape drivers as I have a use for them, be it in the official sources or locally, that all depends on how the cake is to be cut... Currently, the ATAPI/CAM patches can coexist peacefully with acd/ast/afd, and it is my intention to keep it that way. :) Thomas. -- [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: i386/boot2.c patches
Le 2002-03-20, John Baldwin écrivait : Looks mostly ok to me. Not entirely sure about the autoboot changes as it looks weird to load(kname) right before you change what kname is. I think the logic must somehow be wrong there. But this is what is currently in the code (as I mentioned in the PR, 36015 is strictly a code clarification, with no functional change). The load() function in boot2 ends with an exec() of the loaded binary. It returns only if it has failed. The purpose of replacing kname after load() has returned is to try to load /boot/kernel if we have failed to load /boot/loader. Thomas. -- [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: cdrecord for ATAPI burners available..
Le 2002-03-19, Søren Schmidt écrivait : ftp://freebsd.dk/pub/ATA/cdrtools-1.10-ATA.tgz On -stable it needs the ATA driver update I did a yesterday. It does *not* need CAM or the atapicam patches, it uses the ATA driver directly.. Alternatively, for those who'd like to use stock issue cdr tools (or any other tool that manipulates CAM devices) there also is a new release of the ATAPI/CAM patches at http://www.cuivre.fr.eu.org/~thomas/atapicam/ that resolves the 'hang at boot' issue reported by several testers with Toshiba units. Users of ATAPI tapes and floppy drives are also welcome to test the patches. Thomas. -- [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: cdrecord for ATAPI burners available..
Le 2002-03-19, Søren Schmidt écrivait : ftp://freebsd.dk/pub/ATA/cdrdao-1.1.5-ATA.tgz Again no CAM or atapicam needed :) Hum this package does not compile out of the box: c++ -DHAVE_CONFIG_H -I.. -I. -I/usr/local/include/pccts -O -pipe -c TocParser.cpp -o TocParser.o TocParser.cpp:512: macro `zzsetmatch' used with too many (2) args gmake[1]: *** [TocParser.o] Error 1 (a 'gmake distclean' is necessary to get rid of various generated file that are specific to your installed version of antlr.) Furhtermore it looks to me like it has a serious drawback. Please feel free to correct me if I am wrong (I am not familiar with libscg internals) but this patched version works /only/ with ATAPI units, which means that if you have both proper SCSI drives and ATAPI drives, then you cannot use the same cdrdao binary for both. This also means that you cannot do on-the-fly cd copies in such a situation. Thomas. -- [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: cdrecord for ATAPI burners available..
Le 2002-03-19, Søren Schmidt écrivait : gmake[1]: *** [TocParser.o] Error 1 You need to have pccts installed to compile cdrdao I do, and as I mentioned in my first message, the compileation completed after a gmake distclean. These utils are ATA only (as the name implies), if our ports people wants to merge it into whats already there I wont complain :) That said I think the ATA only version covers more than a significant percentage of our userbase In which case I'll be more than happy to continue maintaining ATAPI/CAM as an alternative solution, which addresses 100% of our user base and does not impose any additional work upon application authors or port maintainers. Thomas. -- [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Updated ATAPI/CAM patches
An updated version of the ATAPI/CAM patches is available from http://www.cuivre.fr.eu.org/~thomas/atapicam/ This version contains no functional changes, but synchronize with recent modifications to the generic ATAPI code. As always, I would be interested in any feedback. Specifically, there is one known pending issue with this code: on *some* machines, patched kernels hang at boot time, immediately after registering the new CAM sim. If it hangs on your machine and you can provide a backtrace of the point where the freeze occurs, it would be most helpful. Enjoy, Thomas. -- [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Updated ATAPI/CAM patches
Wow /that's/ a thread ;) On Thu, 28 Feb 2002, Søren Schmidt wrote: I'll quit the ATA/ATAPI development/maintenance if this goes in quickly. First of all I'd like to make two points: * Søren is doing a great job as ATA maintainer, and it would be a Bad Thing to have him quit; * I am not particularly pushing for quick integration of the code into the system. Quite some review and debugging is in order, as well as some discussion with the CAM team as to how to properly handle variations in devices' command sets (the current patch intercepts and translates some SCSI commands on the fly -- this is working, but a ugly hack.) Read the rest of my mail, the problem is not the patches as much as it is all the issues getting it to work and helping users I have been maintaining the patch and helping users with it since the time I first published it. It is none of my intentions to impose upon anyone else the burden of taking care of it. As I have stated several times, I have no problem with ATAPI being sent through CAM as long as the usual way stays As far as I was able to determine, my patch does not prevent the use of the existing ATAPI devices. If it does break them, I'd be more than willing to make any necessary changes to remedy that. So if we can get *serious* commitment from a committer to take up these loose ends, lets talk about what to do, if not my offer stands :) What I can offer is serious commitment from a non-presently-committer. Thomas. -- [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Updated ATAPI/CAM patches
Le 2002-02-28, Søren Schmidt écrivait : I have no problem with you doing it, I was just fishing for getting Thomas into the net also, we need all the hands we can get :) As I mentioned I am entirely willing to take charge of the care and feeding of the bugs I wrote. Thomas. -- [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Support for atapi cdrw as scsi in -current?
Is there a place where I can find this updated patch which will work for me in the current -current? Thanks. I put up updated patches at http://www.cuivre.fr.eu.org/~thomas/atapicam/ For -CURRENT, you should be using the latest one (of today) which fixes a silly line inversion. I'd be very interested in success/failuire reports on this patch, especially with ATAPI tape or floppy drives. Thomas. -- [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
conf/31358: Updated patch for -CURRENT
Attached to this email is an update to the patch supplied with PR
conf/31358, which fixes two issues:
* amd can only be started when NFS client is enabled;
* when nfs_client_enable is set and no NFS file systems are mounted
at boot time from /etc/fstab, rc.network needs to ensure that the
nfsclient module is loaded.
Can someone please take a look at this PR?
Thanks,
Thomas.
diff -u ../rc rc
--- ../rc Tue Jan 8 10:11:48 2002
+++ rc Tue Jan 8 10:42:38 2002
@@ -103,6 +103,7 @@
}
chkdepend amd amd_enableportmap portmap_enable
+chkdepend amd amd_enableNFSnfs_client_enable
chkdepend NFS nfs_server_enable portmap portmap_enable
chkdepend NIS nis_server_enable portmap portmap_enable
chkdepend NIS nis_client_enable portmap portmap_enable
diff -u ../rc.network rc.network
--- ../rc.network Tue Jan 8 10:11:48 2002
+++ rc.network Tue Jan 8 10:57:58 2002
@@ -712,8 +712,30 @@
;;
esac
+ # Handle absent nfs client support
+ if sysctl vfs.nfs /dev/null 21; then
+ nfsclient_in_kernel=1
+ else
+ nfsclient_in_kernel=0
+ fi
+
case ${nfs_client_enable} in
[Yy][Ee][Ss])
+ kldload nfsclient nfsclient_in_kernel=1
+
+ case $nfsclient_in_kernel in
+ 1)
+ ;;
+ *)
+ echo 'Warning: NFS client kernel module failed to load'
+ nfs_client_enable=NO
+ ;;
+ esac
+ ;;
+ esac
+
+ case ${nfs_client_enable} in
+ [Yy][Ee][Ss])
if [ -n ${nfs_access_cache} ]; then
echo -n NFS access cache time=${nfs_access_cache}
sysctl
vfs.nfs.access_cache_timeout=${nfs_access_cache} /dev/null
@@ -732,6 +754,27 @@
echo -n ' rpc.lockd'; rpc.lockd
;;
esac
+
+ case ${amd_enable} in
+ [Yy][Ee][Ss])
+ echo -n ' amd'
+ case ${amd_map_program} in
+ [Nn][Oo] | '')
+ ;;
+ *)
+ amd_flags=${amd_flags} `eval\
+ ${amd_map_program}`
+ ;;
+ esac
+
+ if [ -n ${amd_flags} ]; then
+ amd -p ${amd_flags}\
+/var/run/amd.pid 2 /dev/null
+ else
+ amd 2 /dev/null
+ fi
+ ;;
+ esac
;;
esac
@@ -742,26 +785,6 @@
rpc.umntall -k
fi
- case ${amd_enable} in
- [Yy][Ee][Ss])
- echo -n ' amd'
- case ${amd_map_program} in
- [Nn][Oo] | '')
- ;;
- *)
- amd_flags=${amd_flags} `eval\
- ${amd_map_program}`
- ;;
- esac
-
- if [ -n ${amd_flags} ]; then
- amd -p ${amd_flags}\
-/var/run/amd.pid 2 /dev/null
- else
- amd 2 /dev/null
- fi
- ;;
- esac
;;
esac
--
Thomas Quinot ** Département Informatique Réseaux ** [EMAIL PROTECTED]
ENST // 46 rue Barrault // 75634 PARIS CEDEX 13
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: conf/31358: Updated patch for -CURRENT
Le 2002-01-08, Thomas Quinot écrivait :
case ${nfs_client_enable} in
[Yy][Ee][Ss])
+kldload nfsclient nfsclient_in_kernel=1
Ooops, this is *far* too aggressive!
Here is a corrected version of the previous patch. Sorry!
diff -u ../rc rc
--- ../rc Tue Jan 8 10:11:48 2002
+++ rc Tue Jan 8 10:42:38 2002
@@ -103,6 +103,7 @@
}
chkdepend amd amd_enableportmap portmap_enable
+chkdepend amd amd_enableNFSnfs_client_enable
chkdepend NFS nfs_server_enable portmap portmap_enable
chkdepend NIS nis_server_enable portmap portmap_enable
chkdepend NIS nis_client_enable portmap portmap_enable
diff -u ../rc.network rc.network
--- ../rc.network Tue Jan 8 10:11:48 2002
+++ rc.network Tue Jan 8 11:12:14 2002
@@ -712,8 +712,33 @@
;;
esac
+ # Handle absent nfs client support
+ if sysctl vfs.nfs /dev/null 21; then
+ nfsclient_in_kernel=1
+ else
+ nfsclient_in_kernel=0
+ fi
+
case ${nfs_client_enable} in
[Yy][Ee][Ss])
+ case $nfsclient_in_kernel in
+ 1)
+ ;;
+ *)
+ if kldload nfsclient
+ then
+ nfsclient_in_kernel=1
+ else
+ echo 'Warning: NFS client kernel module failed
+to load'
+ nfs_client_enable=NO
+ fi
+ ;;
+ esac
+ ;;
+ esac
+
+ case ${nfs_client_enable} in
+ [Yy][Ee][Ss])
if [ -n ${nfs_access_cache} ]; then
echo -n NFS access cache time=${nfs_access_cache}
sysctl
vfs.nfs.access_cache_timeout=${nfs_access_cache} /dev/null
@@ -732,6 +757,27 @@
echo -n ' rpc.lockd'; rpc.lockd
;;
esac
+
+ case ${amd_enable} in
+ [Yy][Ee][Ss])
+ echo -n ' amd'
+ case ${amd_map_program} in
+ [Nn][Oo] | '')
+ ;;
+ *)
+ amd_flags=${amd_flags} `eval\
+ ${amd_map_program}`
+ ;;
+ esac
+
+ if [ -n ${amd_flags} ]; then
+ amd -p ${amd_flags}\
+/var/run/amd.pid 2 /dev/null
+ else
+ amd 2 /dev/null
+ fi
+ ;;
+ esac
;;
esac
@@ -742,26 +788,6 @@
rpc.umntall -k
fi
- case ${amd_enable} in
- [Yy][Ee][Ss])
- echo -n ' amd'
- case ${amd_map_program} in
- [Nn][Oo] | '')
- ;;
- *)
- amd_flags=${amd_flags} `eval\
- ${amd_map_program}`
- ;;
- esac
-
- if [ -n ${amd_flags} ]; then
- amd -p ${amd_flags}\
-/var/run/amd.pid 2 /dev/null
- else
- amd 2 /dev/null
- fi
- ;;
- esac
;;
esac
--
Thomas Quinot ** Département Informatique Réseaux ** [EMAIL PROTECTED]
ENST // 46 rue Barrault // 75634 PARIS CEDEX 13
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: conf/31358: Updated patch for -CURRENT
Le 2002-01-08, Sheldon Hearn écrivait : Nits follow: [ whitespace ] [ style ] I'd suggest getting your patch tested by -CURRENT users by posting the patch to the freebsd-current mailing list. I have produced a new diff that incorporates the changes suggested by Sheldon. Those interested can fetch it from http://www.cuivre.fr.eu.org/~thomas/31358.diff Thomas. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: reboot -p
Le 2001-12-27, Garance A Drosihn écrivait : If I understand your request, you would want shutdown -p now to behave the same as shutdown -r now if the operating system does not know how to power down the hardware. Is that what you want? Actually what I want would be more like support for a combination like: shutdown -r -p now (which is currently unsupported because we have assigned one signal that says init 'shutdown -r' and another for 'shutdown -p', but that's not the issue here.) More precisely, right now if you do reboot -p then you have exactly the same behaviour as halt -p I.e. try to power down the system, and if the power down fails, then halt. What I would like to have is a means to try to powerdown the system, and if the powerdown fails, then reboot. This comes in handy in the following scenario: 1. UPS signals impending low battery condition; 2. UPS monitoring daemon starts shutdown; 3. kernel syncs buffers and umounts file systems; 4. using an ad hoc event handler registered in shutdown_final, we then signal the UPS that it can stop outputting AC from the battery backup (this is the powerdown action); If the UPS is still on battery power at stage 4, then it will actually power down the machine. On the other hand, if power was restored after stage 2 (eg while the kernel was flushing its buffers), then the signalling at stage 4 will have no effect and the machine needs to reboot. An alternative solution is to make a special-purpose binary that calls shutdown(2) with RB_POWER set and RB_HALT cleared, or to use a different method altogether for starting that emergency powerdown/reboot sequence. On the other hand, it seems to me that RB_POWER should be the proper way of requesting a powerdown action from the kernel. Thomas. -- [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
reboot -p
Currently, when reboot is invoked with the '-p' command line flag (powerdown), it performs a shutdown with RB_HALT|RB_POWEROFF. In some situations, it can be useful to try to perform a poweroff, but reboot if it fails (e.g. when you are shutting down the system as a result of a power failure, you want the system to reboot, *not* stay down, if power was restored after the start of the shutdown procedure). It would be nice if reboot was changed to pass only RB_POWEROFF (without RB_HALT) when invoked with '-p'. Of course halt(8) whould be unaffected and still pass RB_HALT|RB_POWEROFF when invoked as halt -p. What do others think of this change: --- reboot.cThu Aug 2 12:01:20 2001 +++ /tmp/reboot.c Wed Dec 26 13:03:45 2001 @@ -93,7 +93,7 @@ break; case 'p': pflag = 1; - howto |= (RB_POWEROFF | RB_HALT); + howto |= RB_POWEROFF; break; case 'q': qflag = 1; -- [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: SCSI-IDE
Le 2001-11-13, Stijn Hoop écrivait : Just curious, but how is the patch progressing? For the moment I am expecting feedback from the testers who have reported problems booting with the patch (esp. on SMP machines). Can I try this out on a -STABLE system somehow? Yes, the patch available from http://www.cuivre.fr.eu.org/~thomas/atapicam/ is against -STABLE. BTW, I have succesfully used it this week-end for playing DVDs with xine and mplayer. Thomas. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Multiple NFS server problems with Solaris 8 clients
Le 2001-10-25, BSD User écrivait : On Wed, 24 Oct 2001, Paul van der Zwan wrote: I have looked at a trace I made using snoop and it shows an NFS_ACL call which [...] It looks like an implementation error in the -current NFS server. I have been digging at traces of 4.4-RELEASE (which works) and -current (which doesn't). Both versions get it wrong. I have no idea why 4.4-RELEASE worked. Thanks for this information! I have opened a PR on that problem earlier yesterday: kern/31479. -- Thomas Quinot ** Département Informatique Réseaux ** [EMAIL PROTECTED] ENST // 46 rue Barrault // 75634 PARIS CEDEX 13 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Multiple NFS server problems with Solaris 8 clients
Le 2001-10-25, Ian Dowse écrivait : I think PROG_UNAVAIL is correct; the packet trace that Thomas provided shows an RPC request with a program ID of 100227 which is not the NFS program ID. Yep. (Incidentally 100227 appears in /etc/rpc as 'nfs_acl'). Try the patch below. Seems to work. Thanks! Thomas. -- Thomas Quinot ** Département Informatique Réseaux ** [EMAIL PROTECTED] ENST // 46 rue Barrault // 75634 PARIS CEDEX 13 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Multiple NFS server problems with Solaris 8 clients
Le 2001-10-14, Paul van der Zwan écrivait : I am using -current box as a homedir server for my Solaris clients and have noticed a wierd problem. Other problems here, with Solaris 2.[68] as clients, and -CURRENT of yesterday as server. ls works, but ls -l issues a 'NFS getacl failed' message *and* waits for a timeout once for each file in the directory. The server is not multi-homed, and a packet capture shows no trace of address mismatch problems. One interesting thing is that the client first does GETATTR on the file (and apparently gets a reply), and then sends some other RPC, to which the server never replies. Could this be the getacl request mentioned in the client error message? I see no mention of getacl whatsoever in the -CURRENT server code. If no such function is implemented, shouldn't we reject the request? A packet capture is available at http://www.infres.enst.fr/~quinot/nfs.cap Client is 137.194.192.1, server is 137.194.162.11. The test consists in first performing an 'ls' on one file, then an 'ls -l' on the same file. Result: ls photos-ta; ls -l photos-ta photos-ta NFS getacl failed for server shalmaneser.enst.fr: error 5 (RPC: Timed out) -rw--- 1 quinot astre474 Oct 18 14:17 photos-ta Thomas. -- Thomas Quinot ** Département Informatique Réseaux ** [EMAIL PROTECTED] ENST // 46 rue Barrault // 75634 PARIS CEDEX 13 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: amd not loading nfsclient.ko in -current of 9/26
Le 2001-10-10, Thomas Quinot écrivait : Sep 28 09:47:19 hunter amd[309]: /net: mount: No such file or directory Sep 28 09:47:19 hunter amd[309]: extra mkdirs required for /net Sep 28 09:47:19 hunter amd[309]: amfs_toplvl_mount: mount_amfs_toplvl failed: Operation not supported by device Problem reproduced here, and resolved likewise (by kldload'ing nfsclient) with a freshly-cvsupped -CURRENT. A proposed patch addressing this issue can now be found in PR conf/31358. Thomas. -- Thomas Quinot ** Département Informatique Réseaux ** [EMAIL PROTECTED] ENST // 46 rue Barrault // 75634 PARIS CEDEX 13 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: NFS: unable to lock and fopen
Le 2001-10-10, NAKAMURA Kazushi écrivait : % inc +inbox ...(many minutes)... inc: unable to lock and fopen /var/mail/kaz I have been having problems with NFS client locking on -CURRENT for some time, cf. PR bin/27231. Thomas. -- Thomas Quinot ** Département Informatique Réseaux ** [EMAIL PROTECTED] ENST // 46 rue Barrault // 75634 PARIS CEDEX 13 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: amd not loading nfsclient.ko in -current of 9/26
Le 2001-09-28, Georg-W. Koltermann écrivait : after upgrading my current a few days ago I find that amd does not work any more: Sep 28 09:47:19 hunter amd[309]: /net: mount: No such file or directory Sep 28 09:47:19 hunter amd[309]: extra mkdirs required for /net Sep 28 09:47:19 hunter amd[309]: amfs_toplvl_mount: mount_amfs_toplvl failed: Operation not supported by device Problem reproduced here, and resolved likewise (by kldload'ing nfsclient) with a freshly-cvsupped -CURRENT. Thomas. -- Thomas Quinot ** Département Informatique Réseaux ** [EMAIL PROTECTED] ENST // 46 rue Barrault // 75634 PARIS CEDEX 13 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Undefined symbol __stderrp ?
After cvsupping and makeing world and kernel this afternoon, when launching a binary linked against libc.so.4 and libm.so.2, I get /usr/libexec/ld-elf.so.1: /usr/lib/libm.so.2: Undefined symbol __stderrp. Binaries linked against libc.so.5 and libm.so.2 work just fine (the symbol is defined in libc.so.5). Shouldn't the major for libm have been bumped as its ABI was changed? Thomas. -- Thomas Quinot ** Département Informatique Réseaux ** [EMAIL PROTECTED] ENST // 46 rue Barrault // 75634 PARIS CEDEX 13 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Undefined symbol __stderrp ?
Ooops. This was discussed here recently. That's what I get for not reading -CURRENT when on holidays *and* not grepping enough of the backlog. Sorry. -- Thomas Quinot ** Département Informatique Réseaux ** [EMAIL PROTECTED] ENST // 46 rue Barrault // 75634 PARIS CEDEX 13 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: top(1) takes ages to start up
Le 2001-09-08, Nick Hibma écrivait : Why don't you add an early-out for namelength = 15 or put the if-statement in the loop: Well, in my case all usernames are = 8 characters, so the proposed changes would not prevent a complete walk of the NIS db. Thomas. -- [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
top(1) takes ages to start up
... because it walks through the entire NIS db just to find out what the
longest user name is (/src/usr.bin/top/machine.c 1.5). At this site,
this means 2800 RPC calls and dozens of seconds when the network and/or
NIS server are busy.
What do others think of the following patch?
Thomas.
--- machine.c.dist Fri Jun 1 00:36:51 2001
+++ machine.c Fri Sep 7 16:31:45 2001
@@ -212,7 +212,7 @@
sysctlbyname(kern.smp.active, smpmode, modelen, NULL, 0) 0) ||
modelen != sizeof(smpmode))
smpmode = 0;
-
+#ifndef NO_GETPWENT
while ((pw = getpwent()) != NULL) {
if (strlen(pw-pw_name) namelength)
namelength = strlen(pw-pw_name);
@@ -223,6 +223,9 @@
namelength = 13;
else if (namelength 15)
namelength = 15;
+#else
+namelength = 8;
+#endif
if ((kd = kvm_open(/dev/null, /dev/null, /dev/null, O_RDONLY, kvm_open))
== NULL)
return -1;
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: SSH remote X problem
Le 2001-09-07, Pete Carah écrivait : On both of my -current systems, I can't remotely display X apps back to my (non-current) laptop. I don't know if this is related to the upgrade in ssh (my suspicion) or some other (likely library) issue. With -CURRENT cvsupped from this afternoon, I can launch an X client on the -CURRENT box and have the X connection forwarded to my -STABLE desktop machine. Thomas. -- Thomas Quinot ** Département Informatique Réseaux ** [EMAIL PROTECTED] ENST // 46 rue Barrault // 75634 PARIS CEDEX 13 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
SSH client .shosts auth broken in -CURRENT?
Did anyone have a chance to look at PR bin/28724? I still cannot get my -current ssh client to connect to an OpenSSH 2.3.0p server using RSAS-Rhosts authentication. I tried with protocol v1 and v2 alike. Other ssh1 clients do connect to the same server with RhostsRSAAuthentication. I have check the setuid bit is set on the client binary. Thomas. -- Thomas Quinot ** Département Informatique Réseaux ** [EMAIL PROTECTED] ENST // 46 rue Barrault // 75634 PARIS CEDEX 13 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: bin/27231: lockd problems
Le 2001-04-23, Thomas Quinot écrivait : deterministic fashion. It also tends to leave the mailbox locked on the server even after quitting. Running lockd with debugging enabled did not show anything that looks like an abnormal condition. I am still seeing this problem on -CURRENT as of: FreeBSD shalmaneser.enst.fr 5.0-CURRENT FreeBSD 5.0-CURRENT #15: Thu Jun 7 17:54:30 CEST 2001 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/SHALMANESER i386 [ Cc: GNATS so the PR can be reopened. ] Thomas. -- Thomas Quinot ** Département Informatique Réseaux ** [EMAIL PROTECTED] ENST // 46 rue Barrault // 75634 PARIS CEDEX 13 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: rpc.lockd: kernel trap 12 with interrupts disabled
Le 2001-05-29, Andrew Gallatin écrivait : In order for a bug report like this to be useful, you need to supply a backtrace from ddb or gdb. See the Kernel Debugging section of the FreeBSD handbook for instructions on how to obtain such information. ddb did not help much: after the two 'kernel trap 12 with interrupts disabled' messages, the hot key does not work anymore. Using gdb on rpc.lockd and some ddb single-stepping, I was able to see that the freeze occurs somewhere during the first call to callrpc(). I'll try a remote GDB session and see if it helps to at least find out where precisely the error occurs. Or maybe I could add a call to panic() when the faulty trap occurs, which would drop me into DDB? Thomas. -- Thomas Quinot ** Département Informatique Réseaux ** [EMAIL PROTECTED] ENST // 46 rue Barrault // 75634 PARIS CEDEX 13 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
rpc.lockd: kernel trap 12 with interrupts disabled
In the hope to check for any recent improvements with lockd, I cvsupped this morning and remade world. I now have a very strange behaviour of lockd: * rc.conf has nfs_server_enable, rpc_lockd_enable and rpc_statd_enable set to YES. * the system seems to boot correclty; rpc.lockd and rpc.statd are mentioned in the 'Starting final network daemons' phase. BUT: * ps ax shows no trace of rpc.lockd * an attempt to manually launch rpc.lockd immediately results in a hard freeze with message 'Kernel trap 12 with interrupts disabled (repeated twice). * launching rpc.lockd with truss shows that the crash occurs (shortly) after it has forked. Thomas. -- Thomas Quinot ** Département Informatique Réseaux ** [EMAIL PROTECTED] ENST // 46 rue Barrault // 75634 PARIS CEDEX 13 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: rpc.lockd: kernel trap 12 with interrupts disabled
Le 2001-05-29, Andrew Gallatin écrivait : Did you also rebuild your kernel? Yep, I did buildworld buildkenrnel installkernel installworld, then mergemaster and reboot. In order for a bug report like this to be useful, you need to supply a backtrace from ddb or gdb. See the Kernel Debugging section of the FreeBSD handbook for instructions on how to obtain such information. Will try that, thanks. Thomas. -- Thomas Quinot ** Département Informatique Réseaux ** [EMAIL PROTECTED] ENST // 46 rue Barrault // 75634 PARIS CEDEX 13 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
world broken (sshd)
It looks like world does not currently compile: some files have been removed from src/crypto/openssh/ a few hours ago, but are still listed in SRCS in secure/usr.sbin/sshd/Makefile. Possible workaround: --- secure/usr.sbin/sshd/Makefile.dist Fri May 4 17:10:19 2001 +++ secure/usr.sbin/sshd/Makefile Fri May 4 18:14:35 2001 @@ -5,8 +5,8 @@ PROG= sshd SRCS= sshd.c auth-rhosts.c auth-passwd.c auth-rsa.c auth-rh-rsa.c \ - pty.c log-server.c login.c servconf.c serverloop.c \ - auth.c auth1.c auth2.c auth-options.c session.c login_access.c dh.c \ + log-server.c servconf.c serverloop.c \ + auth.c auth1.c auth2.c auth-options.c session.c dh.c \ auth-pam.c MAN= sshd.8 -- Thomas Quinot ** Département Informatique Réseaux ** [EMAIL PROTECTED] ENST // 46 rue Barrault // 75634 PARIS CEDEX 13 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
lockd problems
Since client side locking was implemented, I am having much trouble reading mail on an NFS-mounted mail spool. The NFS server is a Solaris 2.6 U250, and I am reading mail using mutt. When lockd is not running, mutt gets EOPNOTSUPP when trying to flock(). When lockd is running, it occasionnally gets EPERM, but not in a deterministic fashion. It also tends to leave the mailbox locked on the server even after quitting. Running lockd with debugging enabled did not show anything that looks like an abnormal condition. Anything I can do to resolve the problem? Or to help finding out what is happening? :) Thomas. -- Thomas Quinot ** Département Informatique Réseaux ** [EMAIL PROTECTED] ENST // 46 rue Barrault // 75634 PARIS CEDEX 13 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: ** HEADS UP ** Groff 1.17 (including -mdocNG) imported
Le 2001-04-17, Ruslan Ermilov crivait : It is my great pleasure to announce the availability of just released Groff 1.17. Please refer to the src/contrib/groff/NEWS for details on what's new in this release. Hum. I have just made world, and can't format man pages anymore. All I get is the following on stdout: Formatting page, please wait...mdoc error: end-macro (.em) respecification is not allowed. (#41) Should this have been `.Em ...'? User Abort. Done. Sources are from cvsup a few hours ago from now. Thomas. -- Thomas Quinot ** Dpartement Informatique Rseaux ** [EMAIL PROTECTED] ENST // 46 rue Barrault // 75634 PARIS CEDEX 13 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ** HEADS UP ** Groff 1.17 (including -mdocNG) imported
Le 2001-04-18, Ruslan Ermilov crivait : cd /usr/src/gnu/usr.bin/groff/tmac make cleandir obj make all install It works here, thanks! -- Thomas Quinot ** Dpartement Informatique Rseaux ** [EMAIL PROTECTED] ENST // 46 rue Barrault // 75634 PARIS CEDEX 13 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
