uvcx ¥ß§YÀ°±zºô¸ô¶}©±Àç·~!! lxlu
Title: ¥ß§YÀ°±zºô¸ô¶}©±Àç·~°µ¥Í·N!! dnjymxjjocxnu ¥ß§YÀ°±zºô¸ô¶}©±Àç·~°µ¥Í·N!! 2¤p®É§Ö³tºô¶»s§@¤Îקï!! ºô¶»s§@¶W§C»ù¥unNT800¤¸. §K¶Oºô§}!!ºô¯¸¤º®e¥i¤À:¤½¥q²¤¶. ²£«~¤¶²Ð. ²£«~¬Û¤ù. «È¤á¯d¨¥ªO. ©wÁʪí³æ. ±m¦â°Êµeµ¥µ¥¦³·NªÌÅwªï¬¢½Í!! ¥»³B´£¨Ñ°Ó®a¹ê¨Ò§@«~®i¥Ü: ½Ð¨Ómail¯Á¨ú!! §¹¦¨ºô¶»s§@. ¥ß§Yª¾·|±zªº§K¶Oºô§}.¦p http://98.to/±zªº©R¦W(¤¤^¤Î¼Æ¦r¬Ò¥i) ¡@ºô¶»s§@©Îקï¯d¨¥ Ápµ¸©m¦W Ápµ¸¹q¸Ü ¤½¥q¦WºÙ ¹q¤l«H½c ¹w¦ôºô¶¼Æ¶q 5¶¥H¤U 5¶-10¶ 10¶¥H¤W ¤£ª¾¹D ¥Ø«eºô§}µL ¦³ ·PÁ±zªº¯d¨¥!!§ÚÌ·|¾¨§Ö»P±zÁpµ¸!! kyehnbecoxqnc
Re: cardbus nonfunctional in -current as of 9/24
Try disabling acpi and let me know what's what. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
lpd: Host name for your address (fe80:....%xl0) unknown
Hi! I don't think that I like this behaviour: alex@oink ~ $ ps ax | grep lpd 15328 ?? Ss 0:00.01 lpd -4 15329 ?? S 0:00.02 lpd -4 alex@oink ~ $ lpq lpd: Host name for your address (fe80::250:baff:fed4:a512%xl0) unknown alex@oink ~ $ ifconfig -a rl0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST mtu 1500 inet 192.168.0.19 netmask 0xff00 broadcast 192.168.0.255 inet6 fe80::250:baff:fed4:a512%rl0 prefixlen 64 scopeid 0x1 ether 00:50:ba:d4:a5:12 media: Ethernet autoselect (100baseTX) status: active lp0: flags=8810POINTOPOINT,SIMPLEX,MULTICAST mtu 1500 faith0: flags=8000MULTICAST mtu 1500 lo0: flags=8049UP,LOOPBACK,RUNNING,MULTICAST mtu 16384 inet6 ::1 prefixlen 128 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x4 inet 127.0.0.1 netmask 0xff00 I don't know why lpd.c's chkhost() gets an INET6 socket, since it only listens on tcp4: alex@oink ~dir $ netstat -a | grep print tcp4 0 0 *.printer *.*LISTEN ccbdd3c0 stream 0 0 ccab3200000 /var/run/printer Odd. Is a link-local address supposed to have a host name anyways? Alex To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: lpd: Host name for your address (fe80:....%xl0) unknown
Hi,
On Sun, 30 Sep 2001 14:54:31 +0200
Alexander Langer [EMAIL PROTECTED] said:
alex I don't think that I like this behaviour:
alex alex@oink ~ $ ps ax | grep lpd
alex 15328 ?? Ss 0:00.01 lpd -4
alex 15329 ?? S 0:00.02 lpd -4
alex alex@oink ~ $ lpq
alex lpd: Host name for your address (fe80::250:baff:fed4:a512%xl0) unknown
Sorry, but I cannot see this message, here.
Could you please tell me how did you do?
alex Odd. Is a link-local address supposed to have a host name anyways?
No. The resolver doesn't do reverse lookup at all. So, I believe you
cannot play with lpr by specifying link-local address.
--
Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan
[EMAIL PROTECTED] [EMAIL PROTECTED] ume@{,jp.}FreeBSD.org
http://www.imasy.org/~ume/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
panic: blockable sleep lock (sx) allproc @ /usr/local/src/sys/kern/kern_proc.c:212
With -current as of last night around 7pm PDT:
IdlePTD 4390912
initial pcb at 320920
panicstr: bremfree: bp 0xc68bf184 not locked
panic messages:
---
panic: blockable sleep lock (sx) allproc @
/usr/local/src/sys/kern/kern_proc.c:212
syncing disks... panic: bremfree: bp 0xc68bf184 not locked
Uptime: 9h46m14s
#0 dumpsys () at /usr/local/src/sys/kern/kern_shutdown.c:488
#1 0xc01cf098 in boot (howto=260) at
/usr/local/src/sys/kern/kern_shutdown.c:331
#2 0xc01cf4d5 in panic (fmt=0xc02b3fcf bremfree: bp %p not locked)
at /usr/local/src/sys/kern/kern_shutdown.c:628
#3 0xc01fd7a1 in bremfree (bp=0xc68bf184) at
/usr/local/src/sys/kern/vfs_bio.c:535
#4 0xc01fedd1 in vfs_bio_awrite (bp=0xc68bf184) at
/usr/local/src/sys/kern/vfs_bio.c:1528
#5 0xc01b2190 in spec_fsync (ap=0xcd9a0994)
at /usr/local/src/sys/fs/specfs/spec_vnops.c:404
#6 0xc01b1d49 in spec_vnoperate (ap=0xcd9a0994)
at /usr/local/src/sys/fs/specfs/spec_vnops.c:119
#7 0xc023b6f5 in ffs_sync (mp=0xc1703200, waitfor=2, cred=0xc0e3ed00,
td=0xc0359f44)
at vnode_if.h:441
#8 0xc0209f76 in sync (td=0xc0359f44, uap=0x0)
at /usr/local/src/sys/kern/vfs_syscalls.c:626
#9 0xc01ced35 in boot (howto=256) at
/usr/local/src/sys/kern/kern_shutdown.c:240
#10 0xc01cf4d5 in panic (fmt=0xc02b0f20 blockable sleep lock (%s) %s @
%s:%d)
at /usr/local/src/sys/kern/kern_shutdown.c:628
#11 0xc01e6054 in witness_lock (lock=0xc035a9a0, flags=0,
file=0xc02ad8e0 /usr/local/src/sys/kern/kern_proc.c, line=212)
at /usr/local/src/sys/kern/subr_witness.c:493
#12 0xc01d3625 in _sx_slock (sx=0xc035a9a0,
file=0xc02ad8e0 /usr/local/src/sys/kern/kern_proc.c, line=212)
at /usr/local/src/sys/kern/kern_sx.c:115
#13 0xc01ca5e4 in pfind (pid=353) at
/usr/local/src/sys/kern/kern_proc.c:212
#14 0xc01e98a2 in selwakeup (sip=0xc179b804) at
/usr/local/src/sys/kern/sys_generic.c:1292
#15 0xc01f33a3 in ptcwakeup (tp=0xc179b828, flag=1)
at /usr/local/src/sys/kern/tty_pty.c:321
#16 0xc01f337a in ptsstart (tp=0xc179b828) at
/usr/local/src/sys/kern/tty_pty.c:310
#17 0xc01f0958 in ttstart (tp=0xc179b828) at
/usr/local/src/sys/kern/tty.c:1409
#18 0xc01f1da9 in tputchar (c=99, tp=0xc179b828) at
/usr/local/src/sys/kern/tty.c:2469
#19 0xc01e291f in putchar (c=99, arg=0xcd9a0be8) at
/usr/local/src/sys/kern/subr_prf.c:306
#20 0xc01e2b9e in kvprintf (
fmt=0xc02add01 alcru: negative time of %ld usec for pid %d (%s)\n,
func=0xc01e28d0 putchar, arg=0xcd9a0be8, radix=10, ap=0xcd9a0c00
Þ/Ìÿ\002\020)
at /usr/local/src/sys/kern/subr_prf.c:489
#21 0xc01e284c in printf (
fmt=0xc02add00 calcru: negative time of %ld usec for pid %d (%s)\n)
at /usr/local/src/sys/kern/subr_prf.c:262
#22 0xc01cdeab in calcru (p=0xcd0e7300, up=0xc189ae00, sp=0xc189ae08,
ip=0x0)
at /usr/local/src/sys/kern/kern_resource.c:669
#23 0xc01c041c in exit1 (td=0xcd0e7404, rv=256) at
/usr/local/src/sys/kern/kern_exit.c:318
#24 0xc01bfdde in sys_exit (td=0xcd0e7404, uap=0xcd9a0d20)
at /usr/local/src/sys/kern/kern_exit.c:110
#25 0xc027543f in syscall (frame={tf_fs = 47, tf_es = 47, tf_ds = 47,
tf_edi = 0,
tf_esi = -1, tf_ebp = -1077937600, tf_isp = -845542028, tf_ebx =
672297256,
tf_edx = 512, tf_ecx = 672374048, tf_eax = 1, tf_trapno = 12, tf_err
= 2,
tf_eip = 671896240, tf_cs = 31, tf_eflags = 643, tf_esp =
-1077937644, tf_ss = 47})
at /usr/local/src/sys/i386/i386/trap.c:1122
#26 0xc026953d in syscall_with_err_pushed ()
--
We will not tire, we will not falter, and we will not fail.
- George W. Bush, President of the United States
September 20, 2001
Do YOU Yahoo!?
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: cvs commit: src/sys/isa psm.c atkbdc_isa.c
On Tue, Sep 25, 2001 at 09:59:28AM -0700, Kazutaka YOKOTA wrote: yokota 2001/09/25 09:59:28 PDT Modified files: sys/isa psm.c atkbdc_isa.c Log: Yet another turn of workaround for psm/ACPI/PnP BIOS problems currently experienced in -CURRENT. This should fix the problem that the PS/2 mouse is detected twice if the acpi module is not loaded on some systems. Revision ChangesPath 1.24 +2 -2 src/sys/isa/atkbdc_isa.c 1.40 +84 -39src/sys/isa/psm.c Can it be that this fix is responsible for PS/2 mouse being detected zero times? :-) :-( Dmesg output is in a separate message. +Anton. -- | Anton Berezin| FreeBSD: The power to serve | | catpipe Systems ApS _ _ |_ | http://www.FreeBSD.org | | [EMAIL PROTECTED](_(_|| |[EMAIL PROTECTED] | | +45 7021 0050| Private: [EMAIL PROTECTED] | To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
4.x apps can't resolve hostnames
Ruslan Ermilov wrote: If this Yahoo! Messenger is the 4.x application, make sure to add COMPAT4X=TRUE to /etc/make.conf. This will remove old libc.so.4 from /usr/lib and install proper one into /usr/lib/compat. While this does install the appropriate libs, network apps from 4.x still can't resolve hostnames. This applies to ymessenger as mentioned above, and cvsup so far. You can get ymessenger at http://messenger.yahoo.com/messenger/download/unix.html Doug -- We will not tire, we will not falter, and we will not fail. - George W. Bush, President of the United States September 20, 2001 Do YOU Yahoo!? To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: panic: blockable sleep lock (sx) allproc @ /usr/local/src/sys/kern/kern_proc.c:212
On Sun, 30 Sep 2001, Doug Barton wrote:
With -current as of last night around 7pm PDT:
IdlePTD 4390912
initial pcb at 320920
panicstr: bremfree: bp 0xc68bf184 not locked
panic messages:
---
panic: blockable sleep lock (sx) allproc @
/usr/local/src/sys/kern/kern_proc.c:212
syncing disks... panic: bremfree: bp 0xc68bf184 not locked
Uptime: 9h46m14s
...
#10 0xc01cf4d5 in panic (fmt=0xc02b0f20 blockable sleep lock (%s) %s @
%s:%d)
at /usr/local/src/sys/kern/kern_shutdown.c:628
#11 0xc01e6054 in witness_lock (lock=0xc035a9a0, flags=0,
file=0xc02ad8e0 /usr/local/src/sys/kern/kern_proc.c, line=212)
at /usr/local/src/sys/kern/subr_witness.c:493
#12 0xc01d3625 in _sx_slock (sx=0xc035a9a0,
file=0xc02ad8e0 /usr/local/src/sys/kern/kern_proc.c, line=212)
at /usr/local/src/sys/kern/kern_sx.c:115
#13 0xc01ca5e4 in pfind (pid=353) at
/usr/local/src/sys/kern/kern_proc.c:212
#14 0xc01e98a2 in selwakeup (sip=0xc179b804) at
/usr/local/src/sys/kern/sys_generic.c:1292
#15 0xc01f33a3 in ptcwakeup (tp=0xc179b828, flag=1)
at /usr/local/src/sys/kern/tty_pty.c:321
#16 0xc01f337a in ptsstart (tp=0xc179b828) at
/usr/local/src/sys/kern/tty_pty.c:310
#17 0xc01f0958 in ttstart (tp=0xc179b828) at
/usr/local/src/sys/kern/tty.c:1409
#18 0xc01f1da9 in tputchar (c=99, tp=0xc179b828) at
/usr/local/src/sys/kern/tty.c:2469
#19 0xc01e291f in putchar (c=99, arg=0xcd9a0be8) at
/usr/local/src/sys/kern/subr_prf.c:306
#20 0xc01e2b9e in kvprintf (
fmt=0xc02add01 alcru: negative time of %ld usec for pid %d (%s)\n,
func=0xc01e28d0 putchar, arg=0xcd9a0be8, radix=10, ap=0xcd9a0c00
Þ/Ìÿ\002\020)
at /usr/local/src/sys/kern/subr_prf.c:489
#21 0xc01e284c in printf (
fmt=0xc02add00 calcru: negative time of %ld usec for pid %d (%s)\n)
at /usr/local/src/sys/kern/subr_prf.c:262
#22 0xc01cdeab in calcru (p=0xcd0e7300, up=0xc189ae00, sp=0xc189ae08,
ip=0x0)
at /usr/local/src/sys/kern/kern_resource.c:669
#23 0xc01c041c in exit1 (td=0xcd0e7404, rv=256) at
/usr/local/src/sys/kern/kern_exit.c:318
#24 0xc01bfdde in sys_exit (td=0xcd0e7404, uap=0xcd9a0d20)
at /usr/local/src/sys/kern/kern_exit.c:110
#25 0xc027543f in syscall (frame={tf_fs = 47, tf_es = 47, tf_ds = 47,
tf_edi = 0,
tf_esi = -1, tf_ebp = -1077937600, tf_isp = -845542028, tf_ebx =
672297256,
tf_edx = 512, tf_ecx = 672374048, tf_eax = 1, tf_trapno = 12, tf_err
= 2,
tf_eip = 671896240, tf_cs = 31, tf_eflags = 643, tf_esp =
-1077937644, tf_ss = 47})
at /usr/local/src/sys/i386/i386/trap.c:1122
#26 0xc026953d in syscall_with_err_pushed ()
This is a well-know bug in printf(9). The TIOCCONS ioctl always gave
non-deterministic crashes. Now it gives determinstic panics when
pintf() is called while sched_lock is held. Work-around: don't use
anything that uses TIOCCONS (xconsole?).
Bruce
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
reappearance of an old bug again? (microtime went backwards)
-current as of the last day or so- anyone else seen? Sep 30 20:47:15 quarm ntpd[239]: kernel time discipline status change 2041 microuptime() went backwards (939.4410978 - 938.949317) microuptime() went backwards (1382.4391199 - 1382.075447) microuptime() went backwards (1382.4391190 - 1382.252820) microuptime() went backwards (1442.4313917 - 1441.807840) microuptime() went backwards (1712.4246230 - 1712.400756) microuptime() went backwards (1811.4370757 - 1811.261143) microuptime() went backwards (1811.4370751 - 1811.671929) microuptime() went backwards (1934.4016347 - 1933.851724) microuptime() went backwards (1937.3816473 - 1936.242822) microuptime() went backwards (1937.3816479 - 1936.687978) microuptime() went backwards (1937.3816473 - 1936.792461) microuptime() went backwards (1937.3816473 - 1937.011415) microuptime() went backwards (1960.4337552 - 1959.992393) microuptime() went backwards (1960.4337567 - 1960.965830) microuptime() went backwards (1985.3978684 - 1984.781996) microuptime() went backwards (1985.3978684 - 1984.857352) microuptime() went backwards (2241.3910344 - 2241.274206) microuptime() went backwards (2458.3750237 - 2457.673501) microuptime() went backwards (2548.4364374 - 2548.592190) microuptime() went backwards (2548.4364374 - 2548.670159) microuptime() went backwards (2560.4124905 - 2559.917046) microuptime() went backwards (2560.4124905 - 2560.722790) microuptime() went backwards (2753.3773692 - 2752.322675) microuptime() went backwards (2796.154103 - 2796.153535) microuptime() went backwards (3005.4345219 - 3005.116923) To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: reappearance of an old bug again? (microtime went backwards)
-current as of the last day or so- anyone else seen? Sep 30 20:47:15 quarm ntpd[239]: kernel time discipline status change 2041 microuptime() went backwards (939.4410978 - 938.949317) Try turning off the ACPI timer: debug.acpi.disable=timer in loader.conf and see if it goes away. I'm still looking for better testing techniques, since it looks like the ACPI timer can't be trusted. 8( To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: reappearance of an old bug again? (microtime went backwards)
Cool. Yes. Will do. It also turns out that even with this being an SMP system with IOAPIC that ACPI still shares an irq with isp0. How odd. On Sun, 30 Sep 2001, Mike Smith wrote: -current as of the last day or so- anyone else seen? Sep 30 20:47:15 quarm ntpd[239]: kernel time discipline status change 2041 microuptime() went backwards (939.4410978 - 938.949317) Try turning off the ACPI timer: debug.acpi.disable=timer in loader.conf and see if it goes away. I'm still looking for better testing techniques, since it looks like the ACPI timer can't be trusted. 8( To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: cvs commit: src/sys/isa psm.c atkbdc_isa.c
Modified files: sys/isa psm.c atkbdc_isa.c Log: Yet another turn of workaround for psm/ACPI/PnP BIOS problems currently experienced in -CURRENT. This should fix the problem that the PS/2 mouse is detected twice if the acpi module is not loaded on some systems. Revision ChangesPath 1.24 +2 -2 src/sys/isa/atkbdc_isa.c 1.40 +84 -39src/sys/isa/psm.c Can it be that this fix is responsible for PS/2 mouse being detected zero times? :-) :-( Dmesg output is in a separate message. This is most likely to be an ACPI problem. Please try disabling the acpi module (unset load_acpi at the loader prompt) and boot -v, then send me dmesg's output. Kazu To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: reappearance of an old bug again? (microtime went backwards)
Cool. Yes. Will do. It also turns out that even with this being an SMP system with IOAPIC that ACPI still shares an irq with isp0. How odd. This is probably an artifact of the PCI interrupt swizzle; the ACPI irq is typically an interrupt line out of the southbridge (where the power management controller typically lives). To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
