Re: ATAng - copying atapi CD
On Wed, Sep 03, 2003 at 07:11:53AM -0400, Bryan Liesner wrote: > On Wed, 3 Sep 2003, Martin wrote: > > > Am Di, 2003-09-02 um 18.56 schrieb Bryan Liesner: > > > dd then gets slower and slower until it seems to grind to a halt. > > > > I have this problems everywhere (not only ATAng), if I'm trying to > > read some of my really old CD-Rs. You should know that they are aging. > > > > Check the surface of the CD-R (the surface is actually the label!). > > On few CD-Rs which have been in my car the label begins to break > > in the outter areas. This can have several reasons: > > - too much UV light (sun) > > - too high humidity > > - and also touching the CD-R on the outter area while holding it > > > > If you notice that your CD-R label looks strange and if you need > > the data, you should backup it fast. > > > No, we're talking about brand new, factory pressed, audio CDs. And on top of that, my Windows XP machine's DVD-ROM was able to raed my *commercial audio CDs* perfectly while the CD-RW in the FreeBSD machine was only able to read about 95% of the discs before it just got stuck. -- Sean Kelly | PGP KeyID: D2E5E296 [EMAIL PROTECTED] | http://www.sean-kelly.org/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ATAng - copying atapi CD
On Tue, Sep 02, 2003 at 12:56:24PM -0400, Bryan Liesner wrote: > > I have a perl script that dd's each audio track from an audio cd. The > tracks are copied just fine until it gets about 75% into a 70 minute > cd. dd then gets slower and slower until it seems to grind to a halt. > eventually, I'll set TIMEOUT messages and won't be able to kill the > current dd process. Same results with DMA or PIO modes. Shorter > (40 minute) CDs make it through the process OK. > > Soren's crdao 1.1.7 for ATAng also grinds to a halt when copying a cd. I saw this on ATAold as well, using cdparanoia, dd, dagrab, etc. I just chalked it up to my drive being stupid, though it did it on several audio discs. So, maybe it isn't me after all? I don't recall seeing any timeout messages, though. And when I say ATAold, I mean ATAold from a week or so before the ATAng commit. -- Sean Kelly | PGP KeyID: D2E5E296 [EMAIL PROTECTED] | http://www.sean-kelly.org/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Remove "options HW_WDOG"?
While working on my software watchdog, it has come to my attention that the "options HW_WDOG" in FreeBSD does absolutely nothing. does anybody actually use this code, or can I purge it in favor of the software watchdog? /usr/src/sys$ find . -type f |xargs grep HW_WDOG ./conf/NOTES:optionsHW_WDOG ./conf/options:HW_WDOG ./kern/kern_shutdown.c:#ifdef HW_WDOG ./kern/kern_shutdown.c:#endif /* HW_WDOG */ All the bit in kern/kern_shutdown.c does is: watchdog_tickle_fn wdog_tickler = NULL; And I can't find that being used anywhere. -- Sean Kelly | PGP KeyID: D2E5E296 [EMAIL PROTECTED] | http://www.sean-kelly.org/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: sporadic disk syncing failures when shutting down
On Sun, Jul 13, 2003 at 12:04:41AM -0400, Jeff Walters wrote: > I hate to even mentioned such an unscientific observation where I made > multiple changes at once, but I'll provide a data point. I also saw this > problem crop up at the same time as I tried the SCHED_ULE scheduler a couple > of months ago. I re-cvsup'ed CURRENT and switched back to SCHED_4BSD and it > went away. I've only seen the behavior while using SCHED_4BSD, but I only switched to the ULE scheduler on the 6th and haven't rebooted since.. -- Sean Kelly | PGP KeyID: D2E5E296 [EMAIL PROTECTED] | http://www.sean-kelly.org/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: sporadic disk syncing failures when shutting down
On Sat, Jul 12, 2003 at 06:36:53PM -0700, Don Lewis wrote: ... > Stopping inetd. > Shutting down daemon processes:Jul 12 09:19:40 scratch upsmon[492]: upsmon parent: > exiting (child exited) > killall: warning: kill -TERM 492: No such process > killall: warning: kill -TERM 488: No such process > healt Waiting (max 60 seconds) for system process `vnlru' to stop...stopped > Waiting (max 60 seconds) for system process `bufdaemon' to stop...stopped > Waiting (max 60 seconds) for system process `syncer' to stop...stopped > > syncing disks, buffers remaining... 54 54 54 54 54 54 54 54 54 54 54 54 54 54 54 54 > 54 54 54 54 > giving up on 54 buffers > Uptime: 6m42s > Terminate ACPI > Rebooting... > > Each time this has happened, fsck finds and nukes a bunch of empty > directories. The last time this happened, the /etc/rc.d/yp* files that > mergmaster updated were missing after the reboot and fsck had done its > work. Nothing has ever shown up in lost+found. > > Has anyone else seen this? I have seen this a lot, but not as much lately. Sadly, I don't have any more data than you on why it happens. I've seen it give up on a rather frighteningly large number of buffers before, though... -- Sean Kelly | PGP KeyID: D2E5E296 [EMAIL PROTECTED] | http://www.sean-kelly.org/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: GEOM panic
On Tue, Jul 08, 2003 at 10:35:47PM +0200, Poul-Henning Kamp wrote:
>
> Can you try this patch ?
...
> diff -u -r1.28 geom_dump.c
> --- geom_dump.c 11 Jun 2003 06:49:15 - 1.28
> +++ geom_dump.c 8 Jul 2003 20:00:45 -
...
> @@ -162,6 +164,8 @@
> sbuf_printf(sb, "\t \n", cp->provider);
> sbuf_printf(sb, "\t r%dw%de%d\n",
> cp->acr, cp->acw, cp->ace);
> + if (cp->geom->flags & G_GEOM_WITHER)
> + ;
> if (cp->geom->dumpconf != NULL) {
> sbuf_printf(sb, "\t \n");
...
Should that be "else if ((cp->geom->dumpconf != NULL)"? I don't know the
code, but I'm basing this question off of what is below in the patch:
> @@ -182,7 +186,9 @@
> sbuf_printf(sb, "\t %jd\n",
> (intmax_t)pp->mediasize);
> sbuf_printf(sb, "\t %u\n", pp->sectorsize);
> - if (pp->geom->dumpconf != NULL) {
> + if (pp->geom->flags & G_GEOM_WITHER)
> + ;
> + else if (pp->geom->dumpconf != NULL) { // <-- HERE
> sbuf_printf(sb, "\t \n");
> pp->geom->dumpconf(sb, "\t", pp->geom, NULL, pp);
> sbuf_printf(sb, "\t \n");
--
Sean Kelly | PGP KeyID: D2E5E296
[EMAIL PROTECTED] | http://www.sean-kelly.org/
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: who am i
On Fri, Jul 04, 2003 at 01:58:13AM +0300, Ruslan Ermilov wrote: > On Fri, Jul 04, 2003 at 12:46:10AM +0200, Richard Arends wrote: > > Hello, > > > > Please take a look at this: ... > > Of course the latest 'who am i' should return 'richard' and not(!) 'root' > > > Yes, this sucks. DES, could you please fix it? This is also in the PR database as bin/53520. http://www.FreeBSD.org/cgi/query-pr.cgi?pr=bin/53520 -- Sean Kelly | PGP KeyID: D2E5E296 [EMAIL PROTECTED] | http://www.zombie.org pgp0.pgp Description: PGP signature
Re: Software watchdog patch
On Sat, Jun 21, 2003 at 06:33:41AM -0700, Hiten Pandya wrote: > On Fri, Jun 20, 2003 at 09:47:07PM -0500, Sean Kelly wrote: > Hello Sean, this stuff looks really promising. Anyways, I > can't comment about the code as I have had no time to read it, > but here are a few mdoc nitpicks I did: I believe I have cleaned up the mdoc issues you pointed out. The updated patch is available at the same URL: http://www.sean-kelly.org/watchdog.diff Thanks for the feedback. -- Sean Kelly | PGP KeyID: D2E5E296 [EMAIL PROTECTED] | http://www.zombie.org pgp0.pgp Description: PGP signature
Software watchdog patch
Greetings. I've been working on a patch which adds software watchdog to the FreeBSD 5.1-CURRENT kernel. Below is an URL to the patch to my work, and I'd appreciate it if anybody interested in this venture would give me their feedback on what I've got and also help debug it. The patch is available here: http://www.sean-kelly.org/watchdog.diff My watchdog patch is two pieces. One half is a kernel patch which adds the watchdog timer checker to hardclock() in sys/kern/kern_clock.c. It also adds a watchdog_fire() function which performs various things on a watchdog timeout. The userland half of the patch adds a watchdogd daemon which periodically wakes up from a sleep to "notify" the kernel that the userland is still intact. This patch also adds a watchdogd(8) manpage, a watchdog(4) manpage, and an /etc/rc.d/watchdogd startup script. In order to utilize the watchdog, you must build a kernel with options WATCHDOG It is also advised that you enable watchdogd to /etc/rc.conf: watchdogd_enable="YES" Three new sysctls are added: debug.watchdog.enabled When this is non-zero, the watchdog is active and hardclock() is verifying that the watchdog timer has not timed out. debug.watchdog.timeout: 20 This is the number of seconds the watchdog can go without a timer update. debug.watchdog.reset: 0 When this sysctl is "touched" (read/write), it resets the watchdog_ticks kernel variable to the value of ticks. When (ticks - watchdog_ticks) > watchdog.timeout seconds, the watchdog fires by calling watchdog_fire(). When the watchdog fires (watchdog_fire()), different things happen depending on the kernel configuration. First, interrupt counts are dumped to the console. Then, if your kernel was built with DDB support, you will get a backtrace and be dropped to the DDB prompt. If your kernel has no DDB support, your kernel will panic and presumably reboot itself. Note that I attempted to stick to style(9). If I did not, please point out my mistakes and I'll be happy to fix them. Also note that this is my first venture writing manpages from scratch, so feel free to tear them apart and mock me. However, I did read mdoc(7) and check them for warnings. I look forward to any feedback, whether positive or negative. -- Sean Kelly | PGP KeyID: D2E5E296 [EMAIL PROTECTED] | http://www.zombie.org pgp0.pgp Description: PGP signature
fdescfs naming inconsistency
This isn't really a big deal, but I've noticed a slight inconsistency in the output of `mount` when a fdescfs is mounted: edgemaster# mount /dev/ad1s1a on / (ufs, local, soft-updates, multilabel) /dev/ad1s1e on /var (ufs, local, soft-updates, multilabel, acls) /dev/ad1s1f on /usr (ufs, local, soft-updates, multilabel, acls) devfs on /dev (devfs, local, multilabel) fdesc on /dev/fd (fdescfs) ^ ^^^ /dev/fd0 on /mnt (msdosfs, local) linprocfs on /usr/compat/linux/proc (linprocfs, local) Notice that while devfs and linprocfs have the 'fs' appended to their name, the fdescfs does not. Shouldn't the output be more like this? fdescfs on /dev/fd (fdescfs) ^^ So far my attempts to find the origin of this in the source have failed. -- Sean Kelly | PGP KeyID: D2E5E296 [EMAIL PROTECTED] | http://www.zombie.org pgp0.pgp Description: PGP signature
USB Quirk Patch: SanDisk ImageMate CF SDDR31 (V:0x0781, P:0x0002)
Whenever I plug my SanDisk SDDR31 CF reader into my 5.1-BETA system,
I am told that the device doesn't support "Get Max Lun". I have added a USB
quirk to my kernel to fix this, and it seems to work perfectly. I would
appreciate if somebody would consider adding this before 5.2-RELEASE.
umass0: SanDisk Corporation ImageMate CompactFlash USB, rev 1.10/0.09, addr 2
umass0: Get Max Lun not supported (STALLED)
The patch below fixes this problem.
Unfortunately, if there is no CF card in the reader, I am greeted with more
fun messages which I am currently unable to find a fix for:
da0: Removable Direct Access SCSI-2 device
da0: 1.000MB/s transfers
da0: Attempt to query device size failed: NOT READY, Medium not present
(da0:umass-sim0:0:0:0): READ CAPACITY. CDB: 25 0 0 0 0 0 0 0 0 0
(da0:umass-sim0:0:0:0): CAM Status: SCSI Status Error
(da0:umass-sim0:0:0:0): SCSI Status: Check Condition
(da0:umass-sim0:0:0:0): NOT READY asc:3a,0
(da0:umass-sim0:0:0:0): Medium not present
(da0:umass-sim0:0:0:0): Unretryable error
Opened disk da0 -> 6
Anyway, here is the USB quirk patch which seems to be solving half the
problem.
Index: sys/dev/usb/umass.c
===
RCS file: /usr/home/ncvs/src/sys/dev/usb/umass.c,v
retrieving revision 1.84
diff -u -p -r1.84 umass.c
--- sys/dev/usb/umass.c 21 May 2003 00:22:07 - 1.84
+++ sys/dev/usb/umass.c 30 May 2003 19:48:33 -
@@ -358,6 +358,9 @@ Static struct umass_devdescr_t umass_dev
UMASS_PROTO_SCSI | UMASS_PROTO_BBB,
WRONG_CSWSIG
},
+ { USB_VENDOR_SANDISK, USB_PRODUCT_SANDISK_SDDR31, RID_WILDCARD,
+ UMASS_PROTO_SCSI | UMASS_PROTO_WIRE, NO_GETMAXLUN
+ },
{ USB_VENDOR_SCANLOGIC, USB_PRODUCT_SCANLOGIC_SL11R, RID_WILDCARD,
UMASS_PROTO_ATAPI | UMASS_PROTO_CBI_I,
NO_QUIRKS
--
Sean Kelly | PGP KeyID: D2E5E296
[EMAIL PROTECTED] | http://www.zombie.org
pgp0.pgp
Description: PGP signature
/etc/rc.d/ipfw
the ipfw_start() function in /etc/rc.d/ipfw is missing a command:
sysctl net.inet.ip.fw.enable=1
edgemaster# /etc/rc.d/ipfw restart
net.inet.ip.fw.enable: 1 -> 0
Flushed all rules.
...
Firewall rules loaded, starting divert daemons:.
edgemaster# sysctl net.inet.ip.fw.enable
net.inet.ip.fw.enable: 0
This simple patch fixes it, and also changes a `sysctl` to a ${SYSCTL_W}.
--- ipfw.oldThu Mar 6 02:22:37 2003
+++ ipfwThu Mar 6 02:31:58 2003
@@ -35,6 +35,7 @@
if [ -r "${firewall_script}" ]; then
. "${firewall_script}"
+ ${SYSCTL_W} net.inet.ip.fw.enable=1 >/dev/null
echo -n 'Firewall rules loaded, starting divert daemons:'
# Network Address Translation daemon
@@ -63,7 +64,7 @@
! checkyesno firewall_logging && return 0
echo 'Firewall logging=YES'
- sysctl net.inet.ip.fw.verbose=1 >/dev/null
+ ${SYSCTL_W} net.inet.ip.fw.verbose=1 >/dev/null
}
load_rc_config $name
--
Sean Kelly | PGP KeyID: D2E5E296
[EMAIL PROTECTED] | http://www.zombie.org
pgp0.pgp
Description: PGP signature
WITNESS panic in netinet/tcp_input.c
xc34c1824
ip = (struct ip *) 0xc34c1810
ipov = (struct ipovly *) 0xc03e3540
inp = (struct inpcb *) 0xc6cce804
optp = (u_char *) 0xc34c1838 "\001\001\b\n\026û\034\022"
optlen = 12
len = -1069664940
tlen = 1409
off = -1069664940
drop_hdrlen = 52
tp = (struct tcpcb *) 0xc75ae42c
thflags = 1
so = (struct socket *) 0xc758b300
todrop = -1069664940
acked = -1069664940
ourfinisacked = -1069664940
needoutput = 0
tiwin = 3225302336
to = {to_flags = 1, to_tsval = 38474, to_tsecr = 123912,
to_cc = 0, to_ccecho = 0, to_mss = 0, to_requested_s_scale = 0 '\0',
to_pad = 0 '\0'}
taop = (struct rmxp_tao *) 0xc03e3554
tao_noncached = {tao_cc = 1461, tao_ccsent = 49209, tao_mssopt = 11371}
headlocked = 0
next_hop = (struct sockaddr_in *) 0x0
rstreason = -1069664940
ip6 = (struct ip6_hdr *) 0x0
isipv6 = 0
#13 0xc024e6ea in ip_input (m=0xc283ff00)
at /usr/src/sys/netinet/ip_input.c:944
ip = (struct ip *) 0xc34c1810
fp = (struct ipq *) 0xc0353989
ia = (struct in_ifaddr *) 0xc6979400
ifa = (struct ifaddr *) 0x0
i = 0
hlen = 20
checkif = 0
sum = 0
pkt_dst = {s_addr = 1148225171}
divert_info = 0
args = {m = 0xc283ff00, oif = 0x0, next_hop = 0x0, rule = 0x0,
eh = 0x0, ro = 0xdf976ce0, dst = 0xc03e6174, flags = 227, f_id = {
dst_ip = 2475061316, src_ip = 3560425173, dst_port = 49209,
src_port = 11371, proto = 6 '\006', flags = 24 '\030'}, divert_rule = 0,
retval = 3224731712}
#14 0xc02348a2 in swi_net (dummy=0x0) at /usr/src/sys/net/netisr.c:230
ni = (struct netisr *) 0xc038cb90
m = (struct mbuf *) 0xc283ff00
bits = 0
i = 0
#15 0xc01ae6c2 in ithread_loop (arg=0xc2818200)
at /usr/src/sys/kern/kern_intr.c:536
ithd = (struct ithd *) 0xc2818200
ih = (struct intrhand *) 0xc280f180
td = (struct thread *) 0xc281aa50
p = (struct proc *) 0xc28199ec
#16 0xc01ad902 in fork_exit (callout=0xc01ae570 , arg=0x0,
frame=0x0) at /usr/src/sys/kern/kern_fork.c:871
td = (struct thread *) 0x0
p = (struct proc *) 0xc28199ec
(kgdb)
edgemaster#
Script done on Wed Mar 5 19:51:29 2003
--
Sean Kelly | PGP KeyID: D2E5E296
[EMAIL PROTECTED] | http://www.zombie.org
pgp0.pgp
Description: PGP signature
USB makes system totally FUBAR
bdwrite: buffer is not busy Uptime: 7m57s umass-sim:4:0:0:func_code 0x0901: Invalid target (target needed) (da0:umass-sim0:0:0:0): Synchronize cache failed, status == 0x39, scsi status == 0x0 Dumping 1279 MB ata1: resetting devices .. done -- Sean Kelly | PGP KeyID: D2E5E296 [EMAIL PROTECTED] | http://www.zombie.org pgp0.pgp Description: PGP signature
Re: Witness problem with sound
On Tue, Mar 04, 2003 at 03:42:43PM -0800, Pete Carah wrote: > Mar 4 14:56:27 port2 kernel: /usr/src/sys/vm/uma_core.c:1330: could sleep with > "pcm0:play:0" locked from /usr/src/sys/dev/sound/pcm/dsp.c:748 > Mar 4 14:56:27 port2 kernel: /usr/src/sys/vm/uma_core.c:1330: could sleep with I'm seeing something somewhat similar here. Whenever I play any audio, I get an endless stream of: malloc() of "64" with the following non-sleepablelocks held: exclusive sleep mutex pcm0:play:1 (pcm channel) r = 0 (0xc6794740) locked @ /usr/src/sys/dev/sound/pcm/dsp.c:673 This is with: FreeBSD edgemaster.zombie.org 5.0-CURRENT FreeBSD 5.0-CURRENT #0: Tue Mar 4 20:30:35 CST 2003 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/ EDGEMASTER i386 FreeBSD Audio Driver (newpcm) Installed devices: pcm0: at io 0xcc00 irq 10 (4p/2r/4v channels duplex default) -- Sean Kelly | PGP KeyID: D2E5E296 [EMAIL PROTECTED] | http://www.zombie.org pgp0.pgp Description: PGP signature
Lock order reversal
I just noticed this during bootup. It is repeatable.
FreeBSD 5.0-CURRENT #1: Mon Jan 27 14:00:00 CST 2003
[EMAIL PROTECTED]:/usr/obj/usr/src/sys/EDGEMASTER
...
Mounting root from ufs:/dev/ad1s1a
cd0 at ata0 bus 0 target 1 lun 0
cd0: Removable CD-ROM SCSI-0 device
cd0: 33.000MB/s transfers
cd0: Attempt to query device size failed: NOT READY, Medium not present - tray open
lock order reversal
1st 0xc6998a54 process lock (process lock) @ /usr/src/sys/kern/kern_descrip.c:2104
2nd 0xc6944234 filedesc structure (filedesc structure) @
/usr/src/sys/kern/kern_descrip.c:2111
sysctl_kern_file(SYSCTL_HANDLER_ARGS)
{
...
LIST_FOREACH(p, &allproc, p_list) {
2104--->PROC_LOCK(p);
xf.xf_pid = p->p_pid;
xf.xf_uid = p->p_ucred->cr_uid;
if ((fdp = p->p_fd) == NULL) {
PROC_UNLOCK(p);
continue;
}
2111--->FILEDESC_LOCK(fdp);
for (n = 0; n < fdp->fd_nfiles; ++n) {
if ((fp = fdp->fd_ofiles[n]) == NULL)
continue;
--
Sean Kelly | PGP KeyID: D2E5E296
[EMAIL PROTECTED] | http://www.zombie.org
msg51149/pgp0.pgp
Description: PGP signature
Re: x11/kdebase3 build?
On Thu, Jan 16, 2003 at 03:14:25PM -0600, Sean Kelly wrote: ... > Is it just me, or does x11/kdebase3 (3.0.5) not build on 5.0-STABLE? ... Yes, I screwed up. I meant 5.0-CURRENT. Was thinking of impending 5.0-RELEASE. -- Sean Kelly | PGP KeyID: D2E5E296 [EMAIL PROTECTED] | http://www.zombie.org msg50390/pgp0.pgp Description: PGP signature
x11/kdebase3 build?
I'm not entirely sure this belongs on -CURRENT, but I couldn't find any KDE specific list similar to -gnome and I seem to recall that the building of KDE3 was a desired goal for FreeBSD 5.0. That said, I apologize in advance if this is the wrong place to take this. Is it just me, or does x11/kdebase3 (3.0.5) not build on 5.0-STABLE? edgemaster# uname -v FreeBSD 5.0-CURRENT #0: Wed Jan 15 12:12:25 CST 2003 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/EDGEMASTER edgemaster# make ... c++ -DHAVE_CONFIG_H -I. -I. -I../.. -I/usr/local/include -I/usr/X11R6/include -pthread -DQT_THREAD_SUPPORT -I/usr/local/include -I/usr/local/include -I/usr/X11R6/include -D_GETOPT_H -D_THREAD_SAFE -DNDEBUG -DNO_DEBUG -O2 -O -pipe -mcpu=pentiumpro -fno-exceptions -fno-check-new -DQT_CLEAN_NAMESPACE -DQT_NO_COMPAT -DQT_NO_ASCII_CAST -c memory.cpp -MT memory.lo -MD -MP -MF .deps/memory.TPlo -fPIC -DPIC -o .libs/memory.o In file included from memory.cpp:448: memory_fbsd.cpp: In member function `void KMemoryWidget::update()': memory_fbsd.cpp:33: `VM_METER' undeclared (first use this function) memory_fbsd.cpp:33: (Each undeclared identifier is reported only once for each function it appears in.) In file included from memory.cpp:448: memory_fbsd.cpp:35:2: warning: #warning "FIXME: Memory_Info[CACHED_MEM]" gmake[3]: *** [memory.lo] Error 1 gmake[3]: Leaving directory `/usr/ports/x11/kdebase3/work/kdebase-3.0.5/kcontrol/info' -- Sean Kelly | PGP KeyID: D2E5E296 [EMAIL PROTECTED] | http://www.zombie.org msg50388/pgp0.pgp Description: PGP signature
fdisk issues?
Hoping to be able to do a disklabel -B again, I just built a kernel with
N O_GEOM. However, I ran into an interesting problem with 'fdisk' when
trying to debug my other "Boot error" problems that boot1 is giving me.
edgemaster# fdisk ad1
Floating exception (core dumped)
In get_params, we have:
...
780 error = ioctl(fd, DIOCGFWSECTORS, &u);
781 if (error == 0)
782 sectors = dos_sectors = u;
783 error = ioctl(fd, DIOCGFWHEADS, &u);
784 if (error == 0)
785 heads = dos_heads = u;
786
787 dos_cylsecs = cylsecs = heads * sectors;
788 disksecs = cyls * heads * sectors;
...
794 error = ioctl(fd, DIOCGMEDIASIZE, &o);
795 if (error == 0) {
796 disksecs = o / u;
797 cyls = dos_cyls = o / (u * dos_heads * dos_sectors);
798 }
...
What happens if the ioctls in lines 780 and/or 783 fail? When we get to
line 797, we're snagged with division by zero.
I shall demonstrate:
Script started on Sun Jan 12 21:57:23 2003
(gdb) break get_parmams
Breakpoint 1 at 0x8049666: file fdisk.c, line 780.
(gdb) run ad1
Starting program: /usr/src/sbin/fdisk/fdisk ad1
Breakpoint 1, get_params () at fdisk.c:780
780 error = ioctl(fd, DIOCGFWSECTORS, &u);
(gdb) s
781 if (error == 0)
(gdb) p error
$1 = -1
(gdb) s
783 error = ioctl(fd, DIOCGFWHEADS, &u);
(gdb) s
784 if (error == 0)
(gdb) p error
$2 = -1
(gdb) s
787 dos_cylsecs = cylsecs = heads * sectors;
(gdb) print heads
$3 = 0
(gdb) p sectors
$4 = 0
(gdb) s
788 disksecs = cyls * heads * sectors;
(gdb) s
790 error = ioctl(fd, DIOCGSECTORSIZE, &u);
(gdb) s
791 if (error != 0)
(gdb) p error
$5 = 0
(gdb) s
794 error = ioctl(fd, DIOCGMEDIASIZE, &o);
(gdb) p u
$6 = 512
(gdb) s
795 if (error == 0) {
(gdb) p error
$7 = 0
(gdb) p o
$8 = 60022480896
(gdb) s
796 disksecs = o / u;
(gdb) s
797 cyls = dos_cyls = o / (u * dos_heads * dos_sectors);
(gdb) p disksecs
$9 = 117231408
(gdb) s
Program received signal SIGFPE, Arithmetic exception.
0x0804ac43 in __divdi3 ()
(gdb) p dos_heads
$10 = 0
(gdb) p dos_sectors
$11 = 0
(gdb) kill
Kill the program being debugged? (y or n) y
(gdb) quit
Script done on Sun Jan 12 21:58:56 2003
I think I might just get out a small magnet and fix my booting problems
manually.
--
Sean Kelly | PGP KeyID: D2E5E296
[EMAIL PROTECTED] | http://www.zombie.org
msg50060/pgp0.pgp
Description: PGP signature
Re: GEOM prevents bootblocks writing
On Sun, Jan 12, 2003 at 12:49:46PM +0100, [EMAIL PROTECTED] wrote: > In message <[EMAIL PROTECTED]>, Sean Kelly writes: > > >Since I haven't seen any response to this, I'll "me too" it in hopes that > >it will get some attention drawn to it. > > boot0cfg and fdisk should work as advertised. edgemaster# boot0cfg -B ad1 boot0cfg: /dev/ad1: ioctl DIOCSMBR: Operation not permitted edgemaster# fdisk -B ad1 ... fdisk: can't write fdisk partition table: Operation not permitted edgemaster# disklabel -B ad1s1 partition c: partition extends past end of unit Warning, partition c doesn't start at 0! Warning, An incorrect partition c may cause problems for standard system utilities partition f: partition extends past end of unit I've tried doing fdisk and boot0cfg even in singleuser with / mounted readonly. Is this really the way it is supposed to work? I do not remember it behaving like this pre-GEOM. > There is an erratum on "disklabel -B" for 5.0-RELEASE. So how the hell do I make it so I can boot my system again? I don't know what I/it did to make it no longer boot, but I can't. Boot0 shows me a list "F1 FreeBSD, F5 Disk 1". If i choose F1, it just beeps at me. I don't even know why it is beeping at me, because that same FreeBSD partition/slice mounts and works if booted via other methods. -- Sean Kelly | PGP KeyID: D2E5E296 [EMAIL PROTECTED] | http://www.zombie.org msg50051/pgp0.pgp Description: PGP signature
Re: GEOM prevents bootblocks writing
Since I haven't seen any response to this, I'll "me too" it in hopes that it will get some attention drawn to it. Not only do I have seem to somehow broken my bootblocks so boot0 beeps at me when I select "F1 FreeBSD", I am now no longer able to write new bootblocks: edgemaster# disklabel -r ad1s1 ... 8 partitions: #size offsetfstype [fsize bsize bps/cpg] a: 1024000 62914564.2BSD 2048 1638490 # (Cyl. 391*- 455*) b: 62914560 swap# (Cyl.0 - 391*) c: 1172262420unused0 0# (Cyl.0 - 7296*) e: 10485760 73154564.2BSD 2048 1638489 # (Cyl. 455*- 1108*) f: 99425026 178012164.2BSD 2048 1638489 # (Cyl. 1108*- 7296*) edgemaster# disklabel -r ad1s1 ... 8 partitions: #size offsetfstype [fsize bsize bps/cpg] a: 1024000 62915194.2BSD 2048 1638490 # (Cyl. 391*- 455*) b: 6291456 63 swap# (Cyl.0*- 391*) c: 117226242 63unused0 0# (Cyl.0*- 7296*) e: 10485760 73155194.2BSD 2048 1638489 # (Cyl. 455*- 1108*) f: 99425026 178012794.2BSD 2048 1638489 # (Cyl. 1108*- 7296*) partition c: partition extends past end of unit Warning, partition c doesn't start at 0! Warning, An incorrect partition c may cause problems for standard system utiliti es partition f: partition extends past end of unit edgemaster# disklabel -B ad1s1 partition c: partition extends past end of unit Warning, partition c doesn't start at 0! Warning, An incorrect partition c may cause problems for standard system utilities partition f: partition extends past end of unit edgemaster# I'm not even sure what is going on here, but something is clearly not right. Like I said, I can't even boot this anymore. F1 FreeBSD F5 Disk 0 Selecting F1 just beeps at me. Fortunately I can still go to disk 0 and boot via boot2. Help :( On Sun, Dec 22, 2002 at 03:38:37AM +0300, Andrey A. Chernov wrote: > Now I can't update my bootblocks to new ones using 'disklabel -B da0s1', > checklabel() disklabel function return error preventing actual write with > following diagnostic: > > partition b: partition extends past end of unit > partition c: partition extends past end of unit > Warning, partition c doesn't start at 0! > Warning, An incorrect partition c may cause problems for standard system utilities > Warning, partition d: size 0, but offset 32 > Warning, partition e: size 0, but offset 32 > Warning, partition f: size 0, but offset 32 > Warning, partition g: size 0, but offset 32 > Warning, partition h: size 0, but offset 32 > > In fact, this is exact the same diagnostic as from 'disklabel -r da0s1': > > # /dev/da0s1c: > type: SCSI > disk: da0s1 > label: > flags: > bytes/sector: 512 > sectors/track: 32 > tracks/cylinder: 64 > sectors/cylinder: 2048 > cylinders: 17500 > sectors/unit: 35842016 > rpm: 3600 > interleave: 1 > trackskew: 0 > cylinderskew: 0 > headswitch: 0 # milliseconds > track-to-track seek: 0# milliseconds > drivedata: 0 > > 8 partitions: > #size offsetfstype [fsize bsize bps/cpg] > a: 34611200 324.2BSD 2048 1638464 # (Cyl.0*- 16900) > b: 1230816 34611232 swap # (Cyl. 16900*- 17500*) > c: 35842016 32unused0 0 # (Cyl.0*- 17500*) > partition b: partition extends past end of unit > partition c: partition extends past end of unit > Warning, partition c doesn't start at 0! > Warning, An incorrect partition c may cause problems for standard system utilities > Warning, partition d: size 0, but offset 32 > Warning, partition e: size 0, but offset 32 > Warning, partition f: size 0, but offset 32 > Warning, partition g: size 0, but offset 32 > Warning, partition h: size 0, but offset 32 > > For comparison see just 'disklabel da0s1' output which indicate no errors > and no mysterious offset 32 in the data: > > # /dev/da0s1c: > type: SCSI > disk: da0s1 > label: > flags: > bytes/sector: 512 > sectors/track: 32 > tracks/cylinder: 64 > sectors/cylinder: 2048 > cylinders: 17500 > sectors/unit: 35842016 > rpm: 3600 > interleave: 1 > trackskew: 0 > cylinderskew: 0 > headswitch: 0 # milliseconds > track-to-track seek: 0# milliseconds > drivedata: 0 > > 8 partitions: > #size offsetfstype [fsize bsize bps/cpg] > a: 3461120004.2BSD 2048 1638464 # (Cyl.0 - 16899) > b: 1230816 34611200 swap # (Cyl. 16900 - 17500*) > c: 358420
Re: `cat /dev/io` leads to system lockup.
On Fri, Dec 20, 2002 at 07:24:15PM +1100, Bruce Evans wrote: > On Fri, 20 Dec 2002, Sean Kelly wrote: > > > On my 5.0-CURRENT kernel built 45 minutes ago, I can bring my system to its > > knees by doing > > > > # cat /dev/io > > > > While I understand that this isn't exactly something one would normally be > > doing, is it really something that should bring the system down? > > No. Writing to /dev/io is not supported. write(2) to a device that > doesn't support writing should return -1 and set errno to ENODEV. > > This was broken mainly by removing the default case from mem.c:mmrw(). > This causes mmrw() to loop endlessly without giving up control. Giant > locking in -current makes this especially fatal -- mmrw() holds Giant > so even most interrupt handlers are blocked. > > In RELENG_4 the only bug near here is that mmrw() returns ENXIO instead > of ENODEV for writes to /dev/io. Thanks for pointing out where the code which handles /dev/io was. I see exactly what you mean, and I came up with a 2 liner that fixes it on my system. Could somebody check/commit this? edgemaster# cat /dev/io cat: /dev/io: Operation not supported by device edgemaster# Index: sys/i386/i386/mem.c === RCS file: /usr/home/ncvs/src/sys/i386/i386/mem.c,v retrieving revision 1.99 diff -p -u -r1.99 mem.c --- sys/i386/i386/mem.c 11 Oct 2002 14:58:28 - 1.99 +++ sys/i386/i386/mem.c 21 Dec 2002 07:54:29 - @@ -195,6 +195,8 @@ mmrw(dev_t dev, struct uio *uio, int fla return (EFAULT); error = uiomove((caddr_t)(int)uio->uio_offset, (int)c, uio); continue; + default: + return (ENODEV); } if (error) -- Sean Kelly | PGP KeyID: D2E5E296 [EMAIL PROTECTED] | http://www.zombie.org msg49155/pgp0.pgp Description: PGP signature
Re: `cat /dev/io` leads to system lockup.
On Thu, Dec 19, 2002 at 11:35:01PM -0800, Nate Lawson wrote: > On Fri, 20 Dec 2002, Sean Kelly wrote: > > On my 5.0-CURRENT kernel built 45 minutes ago, I can bring my system to its > > knees by doing > > > > # cat /dev/io > > > > While I understand that this isn't exactly something one would normally be > > doing, is it really something that should bring the system down? > > You're running as root. So does "yes > /dev/da0" and "cat /dev/urandom > > /dev/mem" and ... (infinity) While I don't really care to test it, I wager that `yes >/dev/da0` will not cause the system to lock hard. But you seem to be talking abot something very different. You are talking about WRITING. I am talking about READING. # cat /dev/da0 # cat /dev/urandom None of these bring the system to its knees. So why does # cat /dev/io totally lock my system solid? According to the manpage: The special file /dev/io is a controlled security hole that allows a pro- cess to gain I/O privileges (which are normally reserved for kernel- internal code). Any process that holds a file descriptor on /dev/io open will get its IOPL bits in the flag register set, thus allowing it to per- form direct I/O operations. This says nothing about what happens if you attempt to read() from /dev/io, as `cat /dev/io` would be expected to do. At the least, there should be a big, fat, blinking WARNING on the manpage telling you that `cat /dev/io` will bring your system down. -- Sean Kelly | PGP KeyID: D2E5E296 [EMAIL PROTECTED] | http://www.zombie.org msg49107/pgp0.pgp Description: PGP signature
`cat /dev/io` leads to system lockup.
On my 5.0-CURRENT kernel built 45 minutes ago, I can bring my system to its knees by doing # cat /dev/io While I understand that this isn't exactly something one would normally be doing, is it really something that should bring the system down? -- Sean Kelly | PGP KeyID: D2E5E296 [EMAIL PROTECTED] | http://www.zombie.org msg49099/pgp0.pgp Description: PGP signature
Re: Repeatable panic from nautilus2
On Sun, Dec 08, 2002 at 06:01:49PM -0600, Alan L. Cox wrote: > Please remove ENABLE_VFS_IOOPT from your kernel configuration. This > code has never been safe for general use. Just for the sake of clusure, that did in fact fix it. Thank you very much. Now I'm off to figure out why a specific image from my digital camera crashes Nautilus2 when it is thumbnailed... Ahh, computers. -- Sean Kelly | PGP KeyID: D2E5E296 [EMAIL PROTECTED] | http://www.zombie.org To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Repeatable panic from nautilus2
On Sun, Dec 08, 2002 at 05:13:26PM -0800, Matthew Dillon wrote: > > :Please remove ENABLE_VFS_IOOPT from your kernel configuration. This > :code has never been safe for general use. > : > :Unfortunately, when it was documented in NOTES, this was fact was > :omitted. > : > :Alan > > After the release, I swear I am going shitcan that damn option. It might be worth noting in ffs(7) as well as NOTES that the option is dangerous. I see no clear indication anywhere that this option is not something one would want to use. -- Sean Kelly | PGP KeyID: D2E5E296 [EMAIL PROTECTED] | http://www.zombie.org To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Machine doesn't reboot or power off.
I've found that when I issue a 'shutdown -r' or the like, my machine never manages to fully reboot itself. It hangs after showing me the uptime. This isn't always the case, but usually it is. I've tried with and without aCPI, and it is no-go in both cases. I"m running -CURRENT from 2 days ago, but it has been like this for a while. Any suggestions on how to debug this? -- Sean Kelly | PGP KeyID: D2E5E296 [EMAIL PROTECTED] | http://www.zombie.org To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Repeatable panic from nautilus2
Whenever x11-fm/nautilus2 starts up and goes to display my home directory
in a window, my kernel panics. This is currently 100% repeatable, but I'm
unable to get a full backtrace because the backtrace is never totally
completed.
While the backtrace is being spit out to my scree from the panic, my system
freezes. It freezes at random times during teh backtrace. Each time it
happens, I'll get different amounts of backtrace before my system is locked
solid. My watchdog patch I posted on -arch a few weeks ago doesn't even
manage to recover it.
I copied down the backtrace by hand, but it might not be too accurate. So
here is my backtrace, with a bit of gdb goodness mixed in.
(I apologize ahead of time for the verbosity of this, but I'm hoping
somebody can make heads or tails of it.)
panic(c03455f2,0,c03455b4,eb,316) at panic+0x95
(kgdb) list *(panic+0x95)
0xc01cbfc5 is in panic (/usr/src/sys/kern/kern_shutdown.c:502).
499 #if defined(DDB)
500 if (newpanic && trace_on_panic)
501 db_print_backtrace();
lockmgr(c6ddd44c,2,0,c72100e0,e583a920) at lockmgr+0x473
(kgdb) list *(lockmgr+0x473)
0xc01b3063 is in lockmgr (/usr/src/sys/kern/kern_lock.c:443).
440 if (lkp->lk_lockholder == pid)
441 panic("lockmgr: draining against myself");
442
443 error = acquiredrain(lkp, extflags);
444 if (error)
445 break;
_vm_map_lock_read(c6ddd410,c035cd8e,a7c,2ce,0) at _vm_map_lock_read+0x2e
(kgdb) list *(_vm_map_lock_read+0x2a)
0xc02d496a is in _vm_map_lock_read (/usr/src/sys/vm/vm_map.c:386).
381 {
382 int error;
383
384 if (map->system_map)
385 GIANT_REQUIRED;
386 error = lockmgr(&map->lock, LK_EXCLUSIVE, NULL, curthread);
387 KASSERT(error == 0, ("%s: failed to get lock", __func__));
388 }
vm_map_lookup(e583a9c0,0,2,e583a9c4,e583a9b4) at vm_map_lookup+0x2e
(kgdb) list *(vm_map_lookup+0x2a)
0xc02d79aa is in vm_map_lookup (/usr/src/sys/vm/vm_map.c:2684).
2681 * Lookup the faulting address.
2682 */
2683
2684vm_map_lock_read(map);
2685#define RETURN(why) \
2686{ \
2687vm_map_unlock_read(map); \
2688return (why); \
vm_fault(c6ddd410,0,2,8,c72100e0) at vm_fault+0xa2
(kgdb) list *(vm_fault+0xa2)
0xc02d0fc2 is in vm_fault (/usr/src/sys/vm/vm_fault.c:214).
213 fs.map = map;
214 result = vm_map_lookup(&fs.map, vaddr, fault_type, &fs.entry,
215 &fs.first_object, &fs.first_pindex, &prot, &wired);
trap_pfault(e583aa90,0,3e,c0379480,3e) at trap_pfault+0xf2
(kgdb) list *(trap_pfault+0xf2)
0xc0316132 is in trap_pfault (/usr/src/sys/i386/i386/trap.c:734).
733 /* Fault in the user page: */
734 rv = vm_fault(map, va, ftype,
735 (ftype & VM_PROT_WRITE) ? VM_FAULT_DIRTY
736 : VM_FAULT_NORMAL)
;
trap(18,10,10,0,1b) at trap+0x3a2
(kgdb) list *(trap+0x3a2)
0xc0315da2 is in trap (/usr/src/sys/i386/i386/trap.c:446).
444 case T_PAGEFLT: /* page fault */
445 (void) trap_pfault(&frame, FALSE, eva);
446 goto out;
calltrap at calltrap+0x5
--- trap 0xc, eip = 0xc02da109, esp = 0xe583aad0, ebp = 0xe583aad0
vm_object_set_flag(0,1000,805c000,e583ab24,e583ab28) at vm_object_set_flag+0x9
(kgdb) list *(vm_object_set_flag+0x9)
0xc02da109 is in vm_object_set_flag (/usr/src/sys/vm/vm_object.c:271).
268 void
269 vm_object_set_flag(vm_object_t object, u_short bits)
270 {
271 object->flags |= bits;
272 }
vm_uiomove(c6d *freeze*
I wish I had a core to go along with this, but the thing freezes hard
before getting to dumping one. If anybody needs any more data, I'm willing
to provide it. It is rather interesting that I have a 100% repeatability
rate with this.
I've fsck'd all my filesystems, and there is no filesystem brokenness that
could remotely cause this.
Help?!
--
Sean Kelly | PGP KeyID: D2E5E296
[EMAIL PROTECTED] | http://www.zombie.org
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: /boot & rcng
On Thu, Nov 21, 2002 at 12:53:21AM -0800, Kris Kennaway wrote: > On Thu, Nov 21, 2002 at 09:39:41AM +0100, Christophe Yayon wrote: ... > > why is the a lilo file in /boot ? compatibility ? > > There isn't..perhaps you're confusing a FreeBSD file with a LILO file > that has the same name. (16) smkelly@edgemaster:~$ ls -l /boot/liloboot -r-xr-xr-x 1 root wheel 212992 Nov 18 11:12 /boot/liloboot http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/boot/i386/liloldr/Makefile says: This is `liloboot', which creates a file which can be treated like a Linux kernel image, and is designed to be dropped into a Linux system and booted via LILO. Once booted, the user is greeted by the FreeBSD loader. This still isn't quite complete, as the the root= specification from LILO isn't currently passed to the loader yet. -- Sean Kelly | PGP KeyID: D2E5E296 [EMAIL PROTECTED] | http://www.zombie.org To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ufs2 extended attributes info
On Wed, Nov 20, 2002 at 04:46:07PM +1030, Ian Moore wrote: > Hi, > I was wondering if anyone knows where there is some info on the extended > attributes in ufs2? The release notes for RC2 just point to > /usr/src/sys/ufs/ufs/README.extattr. SInce I don't want to download the whole > of -current, I was hoping there might be some info on the 'net somewhere? http://www.freebsd.org/cgi/cvsweb.cgi/~checkout~/src/sys/ufs/ufs/README.extattr -- Sean Kelly | PGP KeyID: 77042C7B [EMAIL PROTECTED] | http://www.zombie.org To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Hi,a little question about DP2.
On Wed, Nov 20, 2002 at 10:29:16AM +0800, kai ouyang wrote: > Hi, Everybody > In the 4.x version, I can use mknod to create a device, for example: > "mknod raidctl c 201 0 root:operator". > But in 5.0, If I use the devfs(default), I do not know how to use some > command You can't `mknod` any device in /dev that isn't known to devfs. Devices are name-based now: edgemaster# ls -l cuaa0 crw-rw 1 uucp dialer 28, 128 Nov 18 14:13 cuaa0 edgemaster# mknod newdevice c 28 128 mknod: newdevice: No such file or directory `mknod` is obsoleted for /dev when using devfs, as the device entries are created and destroyed dynamically as devices are detected and removed from the system. If you accidentally delete a device and aren't sure what the major/minor of it was to recreate it, try something like this: edgemaster# rm cuaa0 edgemaster# ls -l cuaa0 ls: cuaa0: No such file or directory edgemaster# devfs rule apply path cuaa0 unhide edgemaster# ls -l cuaa0 crw-rw 1 uucp dialer 28, 128 Nov 18 14:13 cuaa0 > to create a device like 'mknod' doing in 4.x. > Another question: > In DP2: I found the disk partition 'd' will be used. I know it never be > used in 4.x, it means the total disk size, right? But in DP2, why it could > be used? Actually it is the 'c' slice that is generally used to indicate the whole disk. This is still the case in 5.0. However, I am unable to tell you what 'd' used to represent. I am also clueless on this particular detail. Hope that helps. -- Sean Kelly | PGP KeyID: 77042C7B [EMAIL PROTECTED] | http://www.zombie.org To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: rmuser
On Sat, Nov 09, 2002 at 04:27:12PM +0100, Eirik Nygaard wrote:
> I have rewritten the rmuser.perl script into C. But got no experiense with at, and I
>see the the perl port got a function that removes any at jobs for the user being
>removed. So I wonderd if anyone could make a patch that does that, any feedback on
>the code or bug reports would also be greate.
>
> I have sent in a mail once before, fixed all the style bugs since them :)
> The source is attached.
I really hope somebody with a commit bit looks at this. I know I don't want
to have to install Perl in 5.0-RELEASE just to use rmuser. This looks much
better than the previous submissions.
My two bit comments on the code below.
> char passwd_file[] = "/etc/master.passwd";
> char passwd_tmp[PATH_MAX] = "/etc/ptmp.X";
> char *passwd_tmp2;
> char group_file[] = "/etc/group";
> char new_group_file[] = "/etc/group.new";
> char mail_dir[] = "/var/mail";
> char crontab_dir[] = "/var/cron/tabs";
> char path[] = "/bin:/sbin:/usr/bin:/usr/sbin";
Consider making a pathnames.h
> printf("\nMatching password entry: \n");
> printf("\t%s:%s:%d:%d:%s:%s\n", password->pw_name, password->pw_passwd,
>password->pw_uid, password->pw_gid, password->pw_dir, password->pw_shell);
It looks like it is done this way now, but does anybody have any
security/privacy concerns with showing the encrypted password like that? Is
it necessary?
Consider strlcpy() as well. I saw a few uses of strncpy(), but strlcpy()
may be better.
Should all your "Warning:" lines be sent to stderr?
There are some places that seem to break style(9). You might want to wrap
long lines and such.
> void
> del_mail()
I *think* this should be del_mail(void). I'm not sure how strictly style(9)
is followed and I don't see a direct example of it though. Somebody else
who enjoys enforcing style(9) might want to reply.
Anyway, I wish you luck in your conquest to contribute and help FreeBSD's
journey away from Perl. I just hope somebody else other than me replies to
this thread and helps you take steps to get this code into the world.
--
Sean Kelly | PGP KeyID: 77042C7B
[EMAIL PROTECTED] | http://www.zombie.org
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: Why is my -current system Hard Locking?
On Mon, Nov 04, 2002 at 07:56:49PM -0800, Joel M. Baldwin wrote: > I'm getting quite frustrated with -current. I've been running it > for years and had relatively few problems. However for quite some > time now I've had a problem with Hard Locks. By Hard Lock I mean > that the system doesn't respond to ether traffic, the keyboard > doesn't respond, the capslock, numlock, and scroll lock keys do > nothing, the corresponding LEDs don't light, and ctrl/alt/del > doesn't reboot the system. The only out is to hit reset. I > don't think this is related to the X FP problem ( although I am > running X11 ). There have been many times when I'd walk in the > morning and find the system had been down for hours. As I > understand the X FP problem, it is a transient that shouldn't take > the system down all night. I just came across this problem for the first time on my -CURRENT from Wed Oct 30. I was in the middle of reading a message in mutt (my MUA) on the console and the system just froze. I was also cvsup'ing ports on another vty at the time. There was no way to get a dump or backtrace. Nothing, including networking, was responding. Here are a few things you might want to try: 1. Check your syslog to get an estimate of when the machine dies. Is it during high disk activity? Mine did it during a ports cvsup. Could it be doing it in relation to the /etc/security stuff? Does it happen around the same times every day? 2. Build a kernel with GDB_REMOTE_CHAT and try a remote gdb session against the kernel? Not sure how much information this will provide, since the machine will most likely stop responding to the remote gdb. 3. Figure out when the problem started happening for the first time and see what was commit'd around then. Incidentally, I've also noticed that my machine freezes on reboots. When I panic or when I issue a system reboot, my kernel never actually manages to reboot the system. It hardlocks after showing the system uptime. I've even tried turning ACPI off in the BIOS and it still does it. My boot messages here: http://www.zombie.org/edgemaster.dmesg My kernel config here: http://www.zombie.org/edgemaster.kernel -- Sean Kelly | PGP KeyID: 77042C7B [EMAIL PROTECTED] | http://www.zombie.org To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
UFS Snapshot deadlock
c750990c93c c7509818
(gdb) list *( ufs_lookup+0xdae)
0xc02bd86e is in ufs_lookup (/usr/src/sys/ufs/ufs/ufs_lookup.c:602).
597 } else if (dp->i_number == dp->i_ino) {
598 VREF(vdp); /* we want ourself, ie "." */
599 *vpp = vdp;
600 } else {
601 error = VFS_VGET(pdp->v_mount, dp->i_ino, LK_EXCLUSIVE, &tdp);
602 if (error)
603 return (error);
604 if (!lockparent || !(flags & ISLASTCN)) {
605 VOP_UNLOCK(pdp, 0, td);
606 cnp->cn_flags |= PDIRUNLOCK;
--
Sean Kelly | PGP KeyID: 77042C7B
[EMAIL PROTECTED] | http://www.zombie.org
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Interesting devfs bug
When playing with jail earlier, I found an interesting bug in devfs. After playing with devfs a bit more, I found that jail isn't necessary to cause the bug to show itself. Here's a copy of the session. The problem should be obvious. edgemaster# uname -a FreeBSD edgemaster.zombie.org 5.0-CURRENT FreeBSD 5.0-CURRENT #0: Fri Oct 25 23:27:50 CDT 2002 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/EDGEMASTER i386 edgemaster# mount -t devfs none /mnt edgemaster# cd /mnt edgemaster# devfs -m . ruleset 10 edgemaster# devfs -m . rule add hide edgemaster# devfs -m . rule add path 'random' unhide edgemaster# devfs -m . rule applyset edgemaster# ln -s random urandom edgemaster# ln -s random urandom edgemaster# ln -s random urandom edgemaster# ln -s random urandom edgemaster# ls random urandom urandom urandom urandom edgemaster# ls -l ls: urandom: No such file or directory ls: urandom: No such file or directory ls: urandom: No such file or directory ls: urandom: No such file or directory total 0 crw-rw-rw- 1 root wheel2, 3 Oct 27 16:00 random edgemaster# rm urandom rm: urandom: No such file or directory edgemaster# ls random urandom urandom urandom urandom edgemaster# cd / edgemaster# umount /mnt -- Sean Kelly | PGP KeyID: 77042C7B [EMAIL PROTECTED] | http://www.zombie.org To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: fsck / and remount failure
On Sun, Oct 27, 2002 at 05:17:44PM -0500, Robert Watson wrote: > Are you using UFS1 extended attributes on that box? Yes. (290) smkelly@edgemaster:~$ grep UFS /usr/src/sys/i386/conf/EDGEMASTER options UFS_DIRHASH options UFS_EXTATTR options UFS_EXTATTR_AUTOSTART options UFS_ACL > I suspect there might > be a bug involving the open flags passed to extended attribute backing > vnodes such that a remount is refused because there are existing vnodes > opened writable. I.e., the extended attribute backing files are opened > FREAD|FWRITE, and since the file system is mounted read-only, remount > refuses to upgrade to a rw mount until they are closed. My guess is that, > in fact, this should be permitted, or we should re-open the backing files > on a remount. I'd like to get this bug fixed, but it is another reason to > recommend UFS2 over UFS1. That would make sense. I had never considered the backing files being the cause of it. If necessary, I can rebuild my kernel without ACLs and EXTATTRs to see if that cures the problem. I haven't switched to UFS2 for a few reasons: * I don't know what state it is in (can I boot from it on x86?) * I don't know how stable it is now * I don't really want to have to go through the hassle of backing up and restoring all my data right now. Oh what I'd give for a conversion tool. Hello? Partition Magic people? *shakes wallet* -- Sean Kelly | PGP KeyID: 77042C7B [EMAIL PROTECTED] | http://www.zombie.org To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
fsck / and remount failure
I just suffered a kernel panic and upon reboot, I noticed that the root filesystem isn't able to be remounted read/write after the fsck: Mounting root from ufs:/dev/ad1s1a WARNING: / was not properly dismounted ... Starting file system checks: /dev/ad1s1a: INCORRECT BLOCK COUNT I=42806 (4 should be 0) (CORRECTED) /dev/ad1s1a: UNREF FILE I=42804 OWNER=smkelly MODE=100600 /dev/ad1s1a: SIZE=8756 MTIME=Oct 27 13:48 2002 (CLEARED) /dev/ad1s1a: UNREF FILE I=42805 OWNER=smkelly MODE=100600 /dev/ad1s1a: SIZE=8630 MTIME=Oct 27 13:48 2002 (CLEARED) /dev/ad1s1a: UNREF FILE I=42806 OWNER=root MODE=100444 /dev/ad1s1a: SIZE=0 MTIME=Oct 27 15:50 2002 (CLEARED) /dev/ad1s1a: FREE BLK COUNT(S) WRONG IN SUPERBLK (SALVAGED) /dev/ad1s1a: SUMMARY INFORMATION BAD (SALVAGED) /dev/ad1s1a: BLK(S) MISSING IN BIT MAPS (SALVAGED) /dev/ad1s1a: 2231 files, 83743 used, 168240 free (424 frags, 20977 blocks, 0.2% fragmentation) /dev/ad1s1e: DEFER FOR BACKGROUND CHECKING /dev/ad1s1f: DEFER FOR BACKGROUND CHECKING /dev/ad0s1c: DEFER FOR BACKGROUND CHECKING mount: /dev/ad1s1a: Device busy mount: /dev/ad1s1a: Device busy Is this a known problem? It is rather annoying to have to come up for fscks, then reboot again to get a read/write root filesystem. Am I doing something wrong? And yes, I know my root filesystem is excessively large. -- Sean Kelly | PGP KeyID: 77042C7B [EMAIL PROTECTED] | http://www.zombie.org To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
"don't do that" w/ snd_emu10k1.ko
When attempting to kldunload snd_emu10k1.ko, I was greeted with a panic
saying "don't do that". I wasn't able to get any traces or anything, as
things went downhill from there. I'm not exactly sure what happened after
that, but it wasn't a graceful crash to say the least. I'll try it again
later for amusement.
Anyway, I would guess that this bit from sys/kern/kern_conf.c is doing it:
void
destroy_dev(dev_t dev)
{
if (!(dev->si_flags & SI_NAMED)) {
printf( "WARNING: Driver mistake: destroy_dev on %d/%d\n",
major(dev), minor(dev));
panic("don't do that");
return;
}
...
I don't recall seeing the WARNING, but things happened rather fast.
Any ideas or anybody else seeing this?
--
Sean Kelly | PGP KeyID: 77042C7B
[EMAIL PROTECTED] | http://www.zombie.org
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
/usr/src/sys/netinet/udp_usrreq.c:290
When booting my system, I get the following after samba-2.2.6 starts: acquiring duplicate lock of same type: "inp" 1st inp @ /usr/src/sys/netinet/udp_usrreq.c:290 2nd inp @ /usr/src/sys/netinet/udp_usrreq.c:290 This is with a kernel from Fri Oct 25 23:27:50 CDT 2002 (about an hour ago). it looks to me that under some conditions, inp isn't being unlocked in the LIST_FOREACH(inp, &udb, inp_list) loop. It is possible I am wrong, though... -- Sean Kelly | PGP KeyID: 77042C7B [EMAIL PROTECTED] | http://www.zombie.org To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
could sleep with "pcm0:play:1" locked
I'm running 5.0-CURRENT from about 15 minutes ago. I'm running with
snd_emu10k1.ko and snd_pcm.ko loaded from loader.conf. When I attempt to do
anything with audio, I get "counld sleep" messages.
edgemaster# head -1 /dev/audio
^C
edgemaster# dmesg|tail -1
/usr/src/sys/vm/uma_core.c:1311: could sleep with "pcm0:record:0" locked from
/usr/src/sys/dev/sound/pcm/sound.c:191
edgemaster# echo "hello" >/dev/audio
edgemaster# dmesg | tail -1
/usr/src/sys/vm/uma_core.c:1311: could sleep with "pcm0:play:1" locked from
/usr/src/sys/dev/sound/pcm/sound.c:191
sys/dev/sound/pcm/sound.c:
188:/* scan for a free channel */
189:SLIST_FOREACH(sce, &d->channels, link) {
190:c = sce->channel;
191:CHN_LOCK(c);
sys/dev/sound/pcm/channel.h:
#ifdef USING_MUTEX
...
#define CHN_LOCK(c) mtx_lock((struct mtx *)((c)->lock))
...
#else
#define CHN_LOCK(c)
...
#endif
I'd suggest a fix, but I'm only pretending to know what I'm doing so far.
--
Sean Kelly | PGP KeyID: 77042C7B
[EMAIL PROTECTED] | http://www.zombie.org
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
DRM
I'm running a 5.0-CURRENT from earlier this morning and receive this notice: /usr/src/sys/kern/kern_sysctl.c:1000: could sleep with "drm memory" locked from @/dev/drm/drm_memory.h:217 I have 'device agp' in my kernel and I've got mga.ko loaded. The notice is raised when doing 'sysctl -a'. If I can provide any more information, let me know. -- Sean M. Kelly [EMAIL PROTECTED] Asst. Unix Systems and Network Admin. Creighton University Computer Center To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Questions about -current
First off, you sent this to the wrong list. Most of the questions you bring up in here should have been directed at -questions. On Mon, Jan 21, 2002 at 09:22:08AM +, [EMAIL PROTECTED] wrote: > I just upgraded to -current today to get a couple of > features including devfs working. In the process I > have run into a few questions (mainly things to do with > the fact that up until a few days ago I was only using > linux 2.4.x): If you are new to FreeBSD, -CURRENT might not be a wise place to start. > 1) Will either the in kernel or oss sound driver for an ... > 3) Will USB keyboards work as the system console > keyboard any time soon, right now I can't seem to get > my Sun Type 6 USB keyboard to work even though it shows > up in dmesg. If you have both a PS/2 and USB keyboard, you need to make use of `kbdcontrol -k`. > 4) Is there anyone actively maintaining dri for XFree86 > on FreeBSD, I couldn't get my Radeon 7500 to work with See /usr/ports/graphics/drm-kmod or http://gladstone.uoregon.edu/~eanholt/dri/ ... > 6) I have found the pages for hardware monitoring > support in the FreeBSD kernel and have a few questions > about it: Will the updated code which supports newer > AMD and VIA monitoring chips be rolled into -current > soon? And if so what userland utility does one use in > FreeBSD to pull values from the driver like lm-sensors > does for Linux? I've got /usr/ports/sysutils/xmbmon/ working perfectly with my setup. -- Sean Kelly | PGP KeyID: 77042C7B [EMAIL PROTECTED] | http://www.zombie.org For PGP key, send e-mail with subject "send pgp key" msg33724/pgp0.pgp Description: PGP signature
Re: S.M.A.R.T.?
On Fri, Oct 05, 2001 at 09:00:44PM +0200, Søren Schmidt wrote: ... > What is it more precisely you want support for ? please keep in mind > that lots of the usefull stuff in SMART is vendor specific... IBM 60GXP, 75GXP (ick) Maxtor DiamondMax Western Digital WD1000BB Caviar So basically, all the bigger, newer IDE drives that seem prone to randomly exploding and eating all your data. I'd ask for some SCSI support too, but I"m just one of those poor student types that can't afford SCSI (or so I tell myself). -- Sean Kelly | PGP KeyID: 77042C7B [EMAIL PROTECTED] | http://www.zombie.org For PGP key, send e-mail with subject "send pgp key" msg32535/pgp0.pgp Description: PGP signature
S.M.A.R.T.?
Since nobody answered me on -questions, I thought I'd try here since this is the active bed of development. Does anybody know if there is planend or active development for S.M.A.R.T. monitoring of IDE/SCSI hard drives? I would think this would be a desirable feature for small server environments, which FreeBSD is used for a lot. -- Sean Kelly | PGP KeyID: 77042C7B [EMAIL PROTECTED] | http://www.zombie.org For PGP key, send e-mail with subject "send pgp key" msg32544/pgp0.pgp Description: PGP signature
Random Lockups
I'm surry I don't have much data to provide, but... I've been experiencing random lockups on a -CURRENT kernel from the August 5th source. I've gotten it a lot when running screen and ssh on two different terminals at the same time, but that is not the only time it happens. Hardware is a 1.2ghz Thunderbird on an ABIT KT7-RAID I'd attach dmesg output or tracebacks, but there are none. It's just a solid lockup. I'm getting no lockups with a kernel built on July 16th... Anybody else seeing this or have ideas how I can debug it further? I'm not sure how to debug a full lockup. -- Sean Kelly | PGP KeyID: 77042C7B [EMAIL PROTECTED] | http://www.zombie.org For PGP key, send e-mail with subject "send pgp key" PGP signature
Re: Building -STABLE on -CURRENT
On Mon, Jan 22, 2001 at 03:46:51PM -0500, Benjamin Lewis wrote: > Robert, > > You wrote: > > > For the last few days (not sure when it started) I've been unable to build > > -STABLE on a -CURRENT machine. This has proven a problem for recent > > RELENG_3 MFC's of security fixes; I've tried upgrading to the most recent > > -CURRENT on the box, making sure /usr/include is updated, et al. I'm > > guessing this is /usr/include pollution in the /usr/src build, but won't > > speculate too much more as I'm travelling tomorrow. Attached below is the > > breakage from buildworld. > > [...] > > > > cd /usr/src/share/syscons/scrnmaps; make build-tools > > cc -static -O -pipe -I/usr/src/share/syscons/scrnmaps > > -DFIL=\"koi8-r2cp866\" > > -o koi8-r2cp866.mk /usr/src/share/syscons/scrnmaps/mkscrfil.c > > In file included from /usr/src/share/syscons/scrnmaps/mkscrfil.c:28: > > /usr/include/machine/console.h:3: #error "this file includes > > > > which is deprecated, use instead" > > I've seen the same thing. I hacked up the -stable source to include the > correct -current include files to get past this, but that strikes me as > extremely non-optimal. I tried hacking up the Makefile in > /usr/src/share/syscons/scrnmaps to use a different include path, but don't > have the know-how or mojo to get that working. I've just hit the same problem... Has anybody got a real fix for this? -- Sean Kelly | PGP KeyID: 77042C7B [EMAIL PROTECTED] | http://www.zombie.org For PGP key, send e-mail with subject "send pgp key" To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
pcm status
What is the current status of the pcm driver? I ask this because I am able to hear sticking and slowdowns in sound when I move my PS/2 mouse. pcm0: at io 0xe800 irq 11 (4p/3r channels duplex) I did not have this behavior in -STABLE, but now I do since I upgraded to -CURRENT. FreeBSD edgemaster 5.0-CURRENT FreeBSD 5.0-CURRENT #0: Mon Jan 15 02:38:13 CST 2001 root@edgemaster:/usr/obj/usr/src/sys/EDGEMASTER i386 I also get many of these: pcm0: hwptr went backwards 2816 -> 2720 pcm0: hwptr went backwards 1760 -> 1568 pcm0: hwptr went backwards 1952 -> 1728 pcm0: hwptr went backwards 0 -> 3872 Other than that, -CURRENT has been very stable (except the time Ioaded vn.ko and the unloaded it and the kernel exploded, leaving me no useful crashdumps no less). -- Sean Kelly | PGP KeyID: 77042C7B [EMAIL PROTECTED] | http://www.zombie.org For PGP key, send e-mail with subject "send pgp key" To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
'host' command with CNAMEs
I've got two machines here, one running 4.1-STABLE (from Aug 3) and a 5.0-CURRENT (from Aug 10) and both of them show the same issue. When you use the 'host' command to resolve a CNAME, it will show all the A records twice: (7) smkelly@edgemaster:~$ host www.microsoft.com www.microsoft.com is a nickname for microsoft.com microsoft.com has address 207.46.130.45 microsoft.com has address 207.46.230.218 microsoft.com has address 207.46.230.219 microsoft.com has address 207.46.230.218 microsoft.com has address 207.46.230.219 microsoft.com has address 207.46.130.45 The host command never used to behave in this way and I'm not sure if it is a bug with the program itself or the resolver. -- Sean Kelly <[EMAIL PROTECTED]> or <[EMAIL PROTECTED]> PGP KeyID: 4AC781C7http://www.sean-kelly.org To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
