subscribe
subscribe -- Andre Naumann | Heinrich Bauer Produktions KG Publishing Support Center | On-Line Team Burchardstr. 11 | 20077 Hamburg Phone: +49 40 3019 5553 | Fax: +49 40 3019 5610 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
i386 tinderbox failure
-- Rebuilding the temporary build tree -- stage 1: bootstrap tools -- stage 2: cleaning up the object tree -- stage 2: rebuilding the object tree -- stage 2: build tools -- stage 3: cross tools -- stage 4: populating /home/des/tinderbox/i386/obj/local0/scratch/des/src/i386/usr/include -- stage 4: building libraries -- stage 4: make dependencies -- stage 4: building everything.. -- Kernel build for GENERIC started on Wed Aug 28 22:34:22 PDT 2002 -- Kernel build for GENERIC completed on Wed Aug 28 23:31:11 PDT 2002 -- Kernel build for LINT started on Wed Aug 28 23:31:12 PDT 2002 -- === xe /local0/scratch/des/src/sys/contrib/dev/acpica/hwregs.c: In function `AcpiGetSleepTypeData': /local0/scratch/des/src/sys/contrib/dev/acpica/hwregs.c:242: warning: cast discards qualifiers from pointer target type /local0/scratch/des/src/sys/contrib/dev/acpica/utglobal.c: In function `AcpiUtGetRegionName': /local0/scratch/des/src/sys/contrib/dev/acpica/utglobal.c:492: warning: cast discards qualifiers from pointer target type /local0/scratch/des/src/sys/contrib/dev/acpica/utglobal.c: In function `AcpiUtGetEventName': /local0/scratch/des/src/sys/contrib/dev/acpica/utglobal.c:530: warning: cast discards qualifiers from pointer target type /local0/scratch/des/src/sys/contrib/dev/acpica/utglobal.c: In function `AcpiUtGetTypeName': /local0/scratch/des/src/sys/contrib/dev/acpica/utglobal.c:607: warning: cast discards qualifiers from pointer target type /local0/scratch/des/src/sys/contrib/dev/acpica/utglobal.c:610: warning: cast discards qualifiers from pointer target type /local0/scratch/des/src/sys/dev/acpica/acpi_acad.c:50: warning: `_THIS_MODULE' defined but not used /local0/scratch/des/src/sys/dev/acpica/acpi_cmbat.c:56: warning: `_THIS_MODULE' defined but not used /local0/scratch/des/src/sys/dev/acpica/acpi_powerres.c:274: warning: `acpi_pwr_deregister_consumer' defined but not used /local0/scratch/des/src/sys/dev/acpica/acpi_powerres.c:212: warning: `acpi_pwr_deregister_resource' defined but not used /local0/scratch/des/src/sys/dev/hea/eni_buffer.c: In function `eni_test_memory': /local0/scratch/des/src/sys/dev/hea/eni_buffer.c:127: warning: passing arg 1 of pointer to function makes pointer from integer without a cast /local0/scratch/des/src/sys/dev/hea/eni_vcm.c: In function `eni_closevcc': /local0/scratch/des/src/sys/dev/hea/eni_vcm.c:289: warning: passing arg 1 of pointer to function makes pointer from integer without a cast /local0/scratch/des/src/sys/dev/ie/if_ie.c: In function `ieattach': /local0/scratch/des/src/sys/dev/ie/if_ie.c:779: warning: assignment discards qualifiers from pointer target type /local0/scratch/des/src/sys/dev/ie/if_ie.c: In function `ieget': /local0/scratch/des/src/sys/dev/ie/if_ie.c:1143: warning: passing arg 1 of `bcopy' discards qualifiers from pointer target type /local0/scratch/des/src/sys/dev/ie/if_ie.c:1232: warning: passing arg 1 of `bcopy' discards qualifiers from pointer target type /local0/scratch/des/src/sys/dev/ie/if_ie.c:1232: warning: passing arg 2 of `bcopy' discards qualifiers from pointer target type /local0/scratch/des/src/sys/dev/ie/if_ie.c:1249: warning: passing arg 1 of `bcopy' discards qualifiers from pointer target type /local0/scratch/des/src/sys/dev/ie/if_ie.c:1261: warning: passing arg 1 of `bcopy' discards qualifiers from pointer target type /local0/scratch/des/src/sys/dev/ie/if_ie.c: In function `ie_readframe': /local0/scratch/des/src/sys/dev/ie/if_ie.c:1304: warning: passing arg 1 of `bcopy' discards qualifiers from pointer target type /local0/scratch/des/src/sys/dev/ie/if_ie.c: In function `iestart': /local0/scratch/des/src/sys/dev/ie/if_ie.c:1403: warning: passing arg 2 of `bcopy' discards qualifiers from pointer target type /local0/scratch/des/src/sys/dev/ie/if_ie.c:1417: warning: cast discards qualifiers from pointer target type /local0/scratch/des/src/sys/dev/ie/if_ie.c: In function `check_ie_present': /local0/scratch/des/src/sys/dev/ie/if_ie.c:1471: warning: passing arg 1 of pointer to function discards qualifiers from pointer target type /local0/scratch/des/src/sys/dev/ie/if_ie.c:1480: warning:
panic: ffs_valloc: dup alloc (with bt + contents of some structures)
Hi,
-current as of around Mon Aug 26 18:39:00 CEST.
After booting the system up xdm didn't showed up and there was no
possibility to login on the console, so I breaked into ddb and send a
kill 1 to xdm. Nothing happened so I again breaked into ddb and did a
kill 1 1. Nothing happened again, so I decided to do a ctrl+t
(several times) - boom.
---snip---
panic: ffs_valloc: dup alloc
panic: from debugger
Uptime: 4m9s
pfs_vncache_unload(): 1 entries remaining
[...]
#7 0xc025573c in kdb_trap (type=3, code=0, regs=0xd1d707cc)
at ../../../i386/i386/db_interface.c:161
#8 0xc0262e8a in trap (frame=
{tf_fs = 24, tf_es = 16, tf_ds = 16, tf_edi = -1033800768, tf_esi = 256, tf_ebp
= -774436848, tf_isp = -774436872, tf_ebx = 0, tf_edx = -1071016644, tf_ecx =
-1070913265, tf_eax = -1070913281, tf_trapno = 3, tf_err = 0, tf_eip = -1071293992,
tf_cs = 8, tf_eflags = 582, tf_esp = -1070958431, tf_ss = -774436824})
at ../../../i386/i386/trap.c:606
#9 0xc02569f8 in calltrap () at {standard input}:98
#10 0xc019ae06 in panic (fmt=0x0) at ../../../kern/kern_shutdown.c:480
#11 0xc020be9b in ffs_valloc () at ../../../ufs/ffs/ffs_alloc.c:871
#12 0xc022bff6 in ufs_makeinode (mode=33200, dvp=0xc27af818, vpp=0xd1d70c14,
cnp=0xd1d70c28) at ../../../ufs/ufs/ufs_vnops.c:2333
#13 0xc02293bc in ufs_create (ap=0xd1d70a6c)
at ../../../ufs/ufs/ufs_vnops.c:197
#14 0xc022c3bb in ufs_vnoperate (ap=0x1) at ../../../ufs/ufs/ufs_vnops.c:2770
#15 0xc01de2ea in vn_open_cred (ndp=0xd1d70c00, flagp=0xd1d70b64, cmode=432,
cred=0xc2c0f500) at vnode_if.h:114
#16 0xc01de168 in vn_open (ndp=0x104, flagp=0xd1d70b64, cmode=432)
at ../../../kern/vfs_vnops.c:91
#17 0xc01d95a3 in open (td=0xc26173c0, uap=0xd1d70d14)
at ../../../kern/vfs_syscalls.c:641
#18 0xc0263873 in syscall (frame=
{tf_fs = 47, tf_es = 47, tf_ds = 47, tf_edi = 136207248, tf_esi = 132, tf_ebp =
136207912, tf_isp = -774435468, tf_ebx = 673750516, tf_edx = 25, tf_ecx = 0, tf_eax =
5, tf_trapno = 0, tf_err = 2, tf_eip = 674051851, tf_cs = 31, tf_eflags = 518, tf_esp
= 136207164, tf_ss = 47}) at ../../../i386/i386/trap.c:1051
#19 0xc0256a4d in Xint0x80_syscall () at {standard input}:140
(kgdb) up 12
(kgdb) list
2328#endif
2329*vpp = NULL;
2330if ((mode IFMT) == 0)
2331mode |= IFREG;
2332
2333error = UFS_VALLOC(dvp, mode, cnp-cn_cred, tvp);
2334if (error)
2335return (error);
2336ip = VTOI(tvp);
2337ip-i_gid = pdir-i_gid;
(kgdb) print *dvp
$2 = {v_interlock = {mtx_object = {lo_class = 0xc02f6400,
lo_name = 0xc029f49b vnode interlock,
lo_type = 0xc029f49b vnode interlock, lo_flags = 196608, lo_list = {
tqe_next = 0x0, tqe_prev = 0x0}, lo_witness = 0x0}, mtx_lock = 4,
mtx_recurse = 0, mtx_blocked = {tqh_first = 0x0, tqh_last = 0xc27af83c},
mtx_contested = {le_next = 0x0, le_prev = 0x0}, mtx_acqtime = 0,
mtx_filename = 0x0, mtx_lineno = 0}, v_iflag = 512, v_usecount = 1,
v_writecount = 0, v_numoutput = 0, v_vxproc = 0x0, v_holdcnt = 2,
v_vflag = 9, v_id = 74, v_mount = 0xc260b600, v_op = 0xc261ba00,
v_freelist = {tqe_next = 0x0, tqe_prev = 0xc26fd2bc}, v_nmntvnodes = {
tqe_next = 0xc27af6f0, tqe_prev = 0xc260b618}, v_cleanblkhd = {
tqh_first = 0x0, tqh_last = 0xc27af894}, v_cleanblkroot = 0x0,
v_dirtyblkhd = {tqh_first = 0xc7775f58, tqh_last = 0xc7775fe4},
v_dirtyblkroot = 0xc7775f58, v_synclist = {le_next = 0x0,
le_prev = 0xc261f0d8}, v_type = VDIR, v_un = {vu_mountedhere = 0x0,
vu_socket = 0x0, vu_spec = {vu_specinfo = 0x0, vu_specnext = {
sle_next = 0x0}}, vu_fifoinfo = 0x0}, v_lastw = 0, v_cstart = 0,
v_lasta = 0, v_clen = 0, v_object = 0xc08386a4, v_lock = {
lk_interlock = 0xc031a4fc, lk_flags = 1088, lk_sharecount = 0,
lk_waitcount = 0, lk_exclusivecount = 1, lk_prio = 72,
lk_wmesg = 0xc02aa4b7 inode, lk_timo = 6, lk_lockholder = 368},
v_vnlock = 0xc27af8e0, v_tag = VT_UFS, v_data = 0xc27acc00, v_cache_src = {
lh_first = 0xc2c27700}, v_cache_dst = {tqh_first = 0x0,
tqh_last = 0xc27af910}, v_dd = 0xc27af818, v_ddid = 0, v_pollinfo = 0x0,
v_label = {l_flags = 0, l_perpolicy = {{l_ptr = 0x0, l_long = 0}, {
l_ptr = 0x0, l_long = 0}, {l_ptr = 0x0, l_long = 0}, {l_ptr = 0x0,
l_long = 0}}}, v_cachedfs = 24322, v_cachedid = 2}
(kgdb) print mode
$3 = 33200
(kgdb) print *cnp
$5 = {cn_nameiop = 1, cn_flags = 52236, cn_thread = 0xc26173c0,
cn_cred = 0xc2c0f500, cn_pnbuf = 0xc2c28000 /tmp/uthread.dump.368.132,
cn_nameptr = 0xc2c28005 uthread.dump.368.132, cn_namelen = 20,
cn_consume = 0}
(kgdb) print *cnp-cn_cred
$6 = {cr_ref = 5, cr_uid = 88, cr_ruid = 88, cr_svuid = 88, cr_ngroups = 2,
cr_groups = {88, 88, 0 repeats 14 times}, cr_rgid = 88, cr_svgid = 88,
cr_uidinfo = 0xc25eb900, cr_ruidinfo = 0xc25eb900, cr_prison = 0x0,
cr_label = {l_flags = 0, l_perpolicy = {{l_ptr = 0x0, l_long = 0}, {
new to BSD
I hope BSD is what I want and need and I can handle it. I got interested reading a guy say that he changed from DOS and in looking for a server who offered a Lynx browser they had BSD as an OS choice so I went looking. The reason why I am looking is that Windows drives me crazy and I want to be able to run on any machine I choose and the less powerfull the better so I don't have to hope that better ones come out to give me more speed. To me Windows seems counter intuitive but then I had a devistating injury that affected everything and my vision sees text better than icons and Small text I can't change. I had a Nice situation with an ISP that had Lynx as an optional browser for text and it flew on any old PC or slow modem. Actually my 14.4K was as fast or faster than my 56K.. I also never had to use a mouse online and with muscle weakness and stamina problems I tired fast and the vagueness of using a mouse drove me buggy when I had to use it and Windows on AOL that I jumped on to get on line but I am having fits with both and a PC they fried so I have reloaded programs many more times than I want to think about. Here's hoping I found an answer. Vince Fontana
Re: lukemftpd not logging wtmp?
On 2002-08-28 23:02 +, Steve Ames wrote: Bah. I spoke to quickly. It looks like PR bin/41556 partially addresses this. So it is a known problem. I'll apply the patch listed in the PR. Sorry to bother. Any comments, suggestions, complaints, etc. whatever you feel that is important for users of the patch, would be a nice addition to the audit trail of the PR, if it's not too much trouble for you to post. Just send a message to [EMAIL PROTECTED] with a subject of: Re: bin/41556: Adding to audit trail. and your message will be added to the text of the proper PR. Thanks, -- FreeBSD: The Power to Serve -- http://www.FreeBSD.org To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Burn-in software
What's a good burn-in software I can use to test the computer and how long should I let it going? What is the optimal temperature of a server room? And in the server? Where can I get a temperature guage for the server and where is the best place to locate it? Thanks. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: CURRENT's termcap broken
÷ Wed, 28.08.2002, × 23:46, Bruce A. Mah ÎÁÐÉÓÁÌ: If memory serves me right, Jens Schweikhardt wrote: # Do you have time to commit mention of it to UPDATING? If so, please # draw Bruce Mah's attention to the delta so that he can steal your text # for use in the release notes. If not, I'll get around to it eventually. # :-) I just added a note to src/UPDATING. Bruce, are you listening for the release notes? 20020827: Our /etc/termcap now has all the entries from the XFree86 xterm almost unchanged. This means xterm now supports color by default. If you used TERM=xterm-color in the past you now should use TERM=xterm. (xterm-color will lead to benign warnings). After this update, xterm-color produce warnings: vbook:/home/vova 129_ mc TERMCAP, line 0, terminal 'xterm-color': enter_alt_charset_mode but no acs_chars TERMCAP, line 0, terminal 'xterm-color': exit_alt_charset_mode but no acs_chars and midnight commander shows all with -, +, | instead of pesudo-graphics. Ok I have tried setenv TERM xterm, midnight commander now black and white, where I have mistaken ? Bruce. -- Vladimir B. Grebenschikov [EMAIL PROTECTED], SWsoft, Inc. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
mozilla regchrome problem is back?
I feel like I stepped into a time warp with -current. I'm getting the old problem building mozilla where it coredumps in regchrome. This was solved back in June and my present mozilla was built on Aug 01 with no problem, so I just took a big step backwards. Anyone else seeing this problem again recently? To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: mozilla regchrome problem is back?
On Thu, Aug 29, 2002 at 01:03:09PM -0700, walt [EMAIL PROTECTED] wrote: I feel like I stepped into a time warp with -current. I'm getting the old problem building mozilla where it coredumps in regchrome. This was solved back in June and my present mozilla was built on Aug 01 with no problem, so I just took a big step backwards. Anyone else seeing this problem again recently? Yes, I've built mozilla 1.0 package yesterday and it went fine, only to find today that it's updated to 1.1 and then there's ./regchrome problem.. -- Vallo Kallaste [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: mozilla regchrome problem is back?
On Thu, Aug 29, 2002 at 16:46:56, [EMAIL PROTECTED] wrote: Yes, I've built mozilla 1.0 package yesterday and it went fine, only to find today that it's updated to 1.1 and then there's ./regchrome problem.. It seems that an important patch (patch-xpcom_reflect_xptcall_src_md_unix_xptc_platforms_unixish_x86.h) has been removed couple of hours ago due to the import of 1.1 is the main reason. Fetch the Attic-moved patch above, and apply manually. (or put under www/mozilla/files) Then it should be built again. Unfortunately, I have not tried yet. (I don't own a powerful, fast, spaceful machine) -- Hidenori Ishikawa [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: new to BSD
On Thu, Aug 29, 2002 at 07:11:17AM -0400, [EMAIL PROTECTED] wrote: I hope BSD is what I want and need and I can handle it. I hope so too, but FreeBSD-current (the development version) is definitely not what you're looking for as a new user. Start off by just installing the latest release (4.6.2 at this time). Please see the handbook on http://www.freebsd.org/ for more information about the FreeBSD development/release model. Kris msg42291/pgp0.pgp Description: PGP signature
Re: new to BSD
Vince, I think this e-mail would be better placed in the newbie's list... You'd probably get a lot more help there... To subscribe: Send mail to [EMAIL PROTECTED] and include the following line in the body of your message: subscribe freebsd-newbies also, from www.freebsd.org: Join the FreeBSD-Questions mailing list to see the questions you were too afraid to ask, and their answers. Subscribe by sending mail to [EMAIL PROTECTED] with subscribe freebsd-questions on its own in the message body (the subject doesn't matter). You can look up old questions and answers via the search page. Here are a couple other excellent resources: http://www.vmunix.com/fbsd-book/index2.html http://www.freebsddiary.org/ http://www.freebsd.org/projects/newbies.html Good luck! __ Do You Yahoo!? Yahoo! Finance - Get real-time stock quotes http://finance.yahoo.com To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: NTFS bugs under -current?
Lars Eggert wrote: I'm mounting my Windows XP partition under both -current and -stable (for the TrueType fonts). Under -stable, accessing files there works fine. Under -current, reads seem to return corrupted data (too short, parts OK, parts garbled). I opened a PR for this: http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/42139 Lars -- Lars Eggert [EMAIL PROTECTED] USC Information Sciences Institute smime.p7s Description: S/MIME Cryptographic Signature
Re: mozilla regchrome problem is back?
On Thu, 2002-08-29 at 09:58, Hidenori Ishikawa wrote: On Thu, Aug 29, 2002 at 16:46:56, [EMAIL PROTECTED] wrote: Yes, I've built mozilla 1.0 package yesterday and it went fine, only to find today that it's updated to 1.1 and then there's ./regchrome problem.. It seems that an important patch (patch-xpcom_reflect_xptcall_src_md_unix_xptc_platforms_unixish_x86.h) has been removed couple of hours ago due to the import of 1.1 is the main reason. Fetch the Attic-moved patch above, and apply manually. (or put under www/mozilla/files) Then it should be built again. Unfortunately, I have not tried yet. (I don't own a powerful, fast, spaceful machine) Yes, this was my fault. The thunks bug was fixed in the Mozilla development tree, and _not_ rolled into 1.1 despite my understanding. The fix will be back in momentarily. Joe -- Hidenori Ishikawa [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message -- PGP Key : http://www.marcuscom.com/pgp.asc To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: mozilla regchrome problem is back?
On 29 Aug 2002, Joe Marcus Clarke wrote: Yes, this was my fault. The thunks bug was fixed in the Mozilla development tree, and _not_ rolled into 1.1 despite my understanding. The fix will be back in momentarily. Joe I hope for a bit longer than THAT.. Seriously, Most Americans don't realise that momentarily is one of the words that divides the US from the UK and the rest of the English speaking world. In the US momentarily means in a moment in other places it usually means for a moment.. now go back and reread what you just wrote :-) it does however accuratly descibe what happenned to the patch before :-) julian To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
PAM
Hi ! After last build of world (few days ago), PAM services started working and now I have trouble logging in with root, and starting X. Is there a way to disable PAM (whole one, not just some modules). Any help is appreciated. Andy ** * Aleksander Rozman - Andy * Fandoms: E2:EA, SAABer, Trekkie, Earthie * * [EMAIL PROTECTED] * Sentinel, BH 90210, True's Trooper, * *[EMAIL PROTECTED] * Heller's Angel, Questie, Legacy, PO5, * * Maribor, Slovenia (Europe) * Profiler, Buffy (Slayerete), Pretender* * ICQ-UIC: 4911125 * * PGP key available *http://www.atechnet.dhs.org/~andy/ * ** To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: mozilla regchrome problem is back?
On Thu, 2002-08-29 at 12:17, Julian Elischer wrote: On 29 Aug 2002, Joe Marcus Clarke wrote: Yes, this was my fault. The thunks bug was fixed in the Mozilla development tree, and _not_ rolled into 1.1 despite my understanding. The fix will be back in momentarily. Joe I hope for a bit longer than THAT.. Seriously, Most Americans don't realise that momentarily is one of the words that divides the US from the UK and the rest of the English speaking world. In the US momentarily means in a moment in other places it usually means for a moment.. now go back and reread what you just wrote :-) it does however accuratly descibe what happenned to the patch before :-) Point taken :-). The patch was added right after I sent the email, and will remain in the tree until the Mozilla group puts out a release that contains said patch. Thanks, Julian :-). Joe julian -- PGP Key : http://www.marcuscom.com/pgp.asc To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
ACPI no longer disabled when APM enabled?
Hi, Since the recent ACPI import (i believe), it seems that ACPI is no longer disabled when APM is enabled. I do not explicitely disable API anywhere, I have the following configuration: device.hints: hint.apm.0.at=nexus hint.apm.0.flags=0x20 kernel config file: device apm device pmtimer In the past, I have seen upon bootup a message apm: Other PM system enabled. and the kernel would carry on booting as if ACPI had not been loaded. Now I see the following: FreeBSD 5.0-CURRENT #15: Thu Aug 29 16:54:05 BST 2002 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/EPSILON Preloaded elf module /boot/kernel/acpi.ko at 0xc05742fc. ... apm: Other PM system enabled. acpi0: TOSHIB 750 on motherboard acpi0: power button is handled as a fixed feature programming model. Timecounter ACPI-safe frequency 3579545 Hz acpi_timer0: 24-bit timer at 3.579545MHz port 0xfe08-0xfe0b on acpi0 acpi_cpu0: CPU on acpi0 acpi_tz0: thermal zone on acpi0 pcib1: ACPI Host-PCI bridge port 0xcf8-0xcff on acpi0 ... acpi_lid0: Control Method Lid Switch on acpi0 acpi_cmbat0: Control method Battery on acpi0 acpi_acad0: AC adapter on acpi0 atkbdc0: Keyboard controller (i8042) port 0x64,0x60 irq 1 on acpi0 etc. Although apm -z still seems to work as expected, closing the lid causes havoc with my IDE controller (i guess it's no real suprise given APM and ACPI are fighting over what to do). I can do a binary search of commits if required, but am pretty certain this is new within the last three days. Gavin To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Call for testers: acpica-unix-20020815
On Sun, Aug 25, 2002 at 06:59:45PM +0200, Mark Santcroos wrote: I have a Dell Latitude C640 and my screen won't come back after a suspend. The machine works fine besides that. FYI: I just did a minimal Linux installation on this machine and tried latest kernel with latest ACPI. Exactly the same behaviour. Mark -- Mark Santcroos RIPE Network Coordination Centre http://www.ripe.net/home/mark/ New Projects Group/TTM To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: ACPI video driver (for Dell Latitude C640)
On Wed, Aug 28, 2002 at 03:43:07PM +0200, Mark Santcroos wrote: It seems that the 'device_resume' functions are called rather unreliably. Most of the time it is not called at all, I couldn't find a pattern yet. Is this a known problem? I worked around this by making the driver a child of pci instead of a child of acpi. (Which is even more correct too) My screen now goes off if I suspend. I also think that I figured out what I need to turn it back on on resume , however I have a problem. However, getting my screen back doesn't work yet. So there might be more too it. (In the worst case, the 'OFF' I do, is different than the 'OFF' the system does, so doing my 'ON' doesn't influence the systems 'OFF') Mark -- Mark Santcroos RIPE Network Coordination Centre http://www.ripe.net/home/mark/ New Projects Group/TTM To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
acpidump: DSDT is corrupt
Hello all, ACPI works pretty well for my machine. PCI routing seems to work (Don't need PCI_ENABLE_IO_MODES anymore, cool!), S1 and S3 sleep modes work (S2 provokes this kernel message: acpi0: AcpiGetSleepTypeData failed - AE_NOT_FOUND). However I cannot get the powerbutton nor the lid switch to work. If I try to run acpidump it prints out some information and then says DSDT is corrupt. Is this because of the errors in the DSDT itself, or is it something else? I have extracted the DSDT using Linux (cat /proc/acpi/dsdt dsdt), and I do not know how to disassemble it, so I have included the binary file in this mail. (I found some link about it on intel's homepages, but the link to a disassembler on Phoenix's homepages was dead) I have a Compal N30N3 computer with VIA PN133 chipset and Phoenix BIOS. Mvh, Frode dsdt.gz Description: GNU Zip compressed data
Re: Signal handling changes
On Thu, 29 Aug 2002, Tim Robbins wrote: It looks like there are still problems with SIGSTOP/SIGCONT signal handling. With a kernel/world from August 24 and using csh or sh (choice of shell is probably not relevant), running sleep 30 then suspending it with ^Z then continuing it with fg causes the sleep process to exit as soon as it's continued, instead of sleeping for the remainder of the interval as it does on 4.6.2. I'm seeing the same behaviour on, erm, surprisingly enough a kernel/world from August 24: FreeBSD gattaca.yadt.co.uk 5.0-CURRENT FreeBSD 5.0-CURRENT #0: Sat Aug 24 02:25:26 BST 2002 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/GATTACA i386 However, at least that shows it isn't any local setup issue, I guess. -- David Taylor [EMAIL PROTECTED] The future just ain't what it used to be To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
fxp0 failures on APCI/APM resume
Hi All, The new apci pci-pci code works wonderfully. However, I've got a problem with the fxp driver not reenabling the device correctly upon a resume from suspend. Details below - Note even when I try to put the laptop into suspend mode S2 which it doesn't support the problem occurs, the only solution is a reboot. Patches welcome. Aug 30 09:38:15 draco kernel: acpi0: AcpiGetSleepTypeData failed - AE_NOT_FOUND Aug 30 09:38:50 draco kernel: fxp0: chip is in D3 power mode -- setting to D0 Aug 30 09:38:52 draco kernel: fxp0: SCB timeout: 0xff 0xff 0xff 0x Aug 30 09:38:52 draco last message repeated 2 times Aug 30 09:38:52 draco kernel: fxp0: DMA timeout Aug 30 09:38:52 draco kernel: fxp0: SCB timeout: 0xff 0xff 0xff 0x Aug 30 09:38:52 draco kernel: fxp0: DMA timeout Aug 30 09:38:52 draco kernel: fxp0: SCB timeout: 0xff 0xff 0xff 0x Aug 30 09:38:52 draco kernel: fxp0: DMA timeout Aug 30 09:38:52 draco kernel: fxp0: SCB timeout: 0xff 0xff 0xff 0x Aug 30 09:38:52 draco kernel: fxp0: SCB timeout: 0xff 0xff 0xff 0x Aug 30 09:38:52 draco kernel: wakeup from sleeping state (slept 00:00:29) Aug 30 09:38:52 draco kernel: ata0: resetting devices .. Aug 30 09:38:52 draco kernel: ata0-slave: ATA identify retries exceeded Aug 30 09:38:52 draco kernel: ad0: DMA limited to UDMA33, non-ATA66 cable or device Aug 30 09:38:52 draco kernel: done Aug 30 09:38:52 draco kernel: ata1: resetting devices .. Aug 30 09:38:52 draco kernel: done Aug 30 09:38:53 draco kernel: fxp0: SCB timeout: 0xff 0xff 0xff 0x Aug 30 09:39:07 draco last message repeated 2 times Aug 30 09:39:08 draco su: benjsc to root on /dev/ttyp2 Aug 30 09:39:11 draco kernel: fxp0: device timeout Aug 30 09:39:12 draco kernel: fxp0: SCB timeout: 0xff 0xff 0xff 0x Aug 30 09:39:12 draco last message repeated 2 times Aug 30 09:39:12 draco kernel: fxp0: DMA timeout Aug 30 09:39:12 draco kernel: fxp0: SCB timeout: 0xff 0xff 0xff 0x Aug 30 09:39:12 draco kernel: fxp0: DMA timeout Aug 30 09:39:12 draco kernel: fxp0: SCB timeout: 0xff 0xff 0xff 0x Aug 30 09:39:12 draco kernel: fxp0: DMA timeout Aug 30 09:39:12 draco kernel: fxp0: SCB timeout: 0xff 0xff 0xff 0x -- 3D Research Associate+61 8 8302 3669 School of Computer and Information Science Room D1-07, Levels Campus University of South AustraliaMawson Lakes Blvd. [EMAIL PROTECTED] South Australia, 5095 F00D C83D 5F7E 5561 DF91 B74D E602 CAA3 4842 B5B4 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: fxp0 failures on APCI/APM resume
The new apci pci-pci code works wonderfully. However, I've got a problem with the fxp driver not reenabling the device correctly upon a resume from suspend. Details below - Note even when I try to put the laptop into suspend mode S2 which it doesn't support the problem occurs, the only solution is a reboot. Patches welcome. Aug 30 09:38:15 draco kernel: acpi0: AcpiGetSleepTypeData failed - AE_NOT_FOUND Aug 30 09:38:50 draco kernel: fxp0: chip is in D3 power mode -- setting to D0 Aug 30 09:38:52 draco kernel: fxp0: SCB timeout: 0xff 0xff 0xff 0x I've had this problem when I didn't have the fxp driver loaded before suspending so it couldn't save the card state. Not sure if it applies in your case but it's something to keep in mind - espcially when testing new stuff where you might not load things as normal. --- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au The nice thing about standards is that there are so many of them to choose from. -- Andrew Tanenbaum To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Ports depending on forbidden compat3x?
Hi, I tried to install acrobatviewer from ports by doing cd /usr/ports/print/acrobatviewer make install The install failed because of the following: Checksum OK for jre1.1.8i_ELF.V1999-11-9.tar.gz. === jre-1.1.8 depends on shared library: c.3 - not found ===Verifying install for c.3 in /usr/ports/misc/compat3x === compat3x-i386-5.0.20020219 is forbidden: FreeBSD-SA-02:28.resolv - buffer overflow in resolver in libc. *** Error code 1 Stop in /usr/ports/misc/compat3x. *** Error code 1 Stop in /usr/ports/java/jre. *** Error code 1 What should I do? -- Craig Rodrigues http://www.gis.net/~craigr [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: [acpi-jp 1770] Re: EC handler doing bad things..
In message [EMAIL PROTECTED], John Baldwin ¤µ¤ó¤¤¤ï¤¯:
On 29-Aug-2002 Mitsuru IWASAKI wrote:
A while back I used to get warnings about temperature events a lot.
I don't get those anymore but now I get a lot of errors when
embedded controller events trigger like so:
ACPI-0433: *** Error: Handler for [EmbeddedControl] returned AE_ERROR
Does anyone have any ideas on why and/or where the best place to look?
For example, which Ec handler is ACPICA calling that is failing?
I don't know why, but it seems that evregion.c:AcpiEvAddressSpaceDispatch(),
acpi_ec.c:EcSpaceHandler() and acpi_ec.c:EcTransaction() are good
cadidate to check out.
Ok, I've found it, reverting this commit makes it work again:
takawata2002/07/01 20:38:07 PDT
Modified files:
sys/dev/acpica acpi_ec.c
Log:
Make interrupt driven EC transaction optional.
Revision ChangesPath
1.26 +2 -0 src/sys/dev/acpica/acpi_ec.c
This commit seems a bit incomplete (it uses an option that isn't setup in
conf/options or defined anywhere). Watanabe-san, can you explain why
you made this change a bit better? It seems to break on at least my
laptop (Dell Inspiron 5000e).
The reason of changing itself is just the same reason as you complain.
(It did not work for at least 2 people including me.)
And I tested a patch so that first the EC try to use interrrupt driven mode
then use polling mode if it failed.
But my keyboard controller (in many cases, it shares ACPI embedded controller)
get wrong by using the patch.
OK. If there are any people that is happy with the interrupt driven mode,
I'll turn it from the #ifdef to TUNABLE_INT option.
The patch are as follows.
Index: /src/sys/dev/acpica/acpi_ec.c
diff -u /src/sys/dev/acpica/acpi_ec.c:1.1.1.1 /src/sys/dev/acpica/acpi_ec.c:1.2
--- /src/sys/dev/acpica/acpi_ec.c:1.1.1.1 Sat Jul 27 14:00:22 2002
+++ /src/sys/dev/acpica/acpi_ec.c Sat Jul 27 14:37:43 2002
@@ -143,7 +143,7 @@
#include machine/bus.h
#include machine/resource.h
#include sys/rman.h
-
+#include sys/sysctl.h
#include acpi.h
#include dev/acpica/acpivar.h
@@ -242,10 +242,14 @@
intec_lockhandle;
intec_pendquery;
intec_csrvalue;
+ int ec_burst;
};
#define EC_LOCK_TIMEOUT1000/* 1ms */
-
+static int ec_readfail = 0;
+static int ec_writefail = 0;
+SYSCTL_INT(_debug, OID_AUTO, acpi_ec_readfail, CTLFLAG_RD, ec_readfail, 0, );
+SYSCTL_INT(_debug, OID_AUTO, acpi_ec_writefail, CTLFLAG_RD, ec_writefail, 0, );
static __inline ACPI_STATUS
EcLock(struct acpi_ec_softc *sc)
{
@@ -289,7 +293,8 @@
static ACPI_STATUS EcTransaction(struct acpi_ec_softc *sc, EC_REQUEST *EcRequest);
static ACPI_STATUS EcRead(struct acpi_ec_softc *sc, UINT8 Address, UINT8 *Data);
static ACPI_STATUS EcWrite(struct acpi_ec_softc *sc, UINT8 Address, UINT8 *Data);
-
+static ACPI_STATUS EcBurstEnable(struct acpi_ec_softc *sc);
+static ACPI_STATUS EcBurstDisable(struct acpi_ec_softc *sc);
static voidacpi_ec_identify(driver_t driver, device_t bus);
static int acpi_ec_probe(device_t dev);
static int acpi_ec_attach(device_t dev);
@@ -371,6 +376,7 @@
/*
* Attach bus resources
*/
+sc-ec_burst = 0;
sc-ec_data_rid = 0;
if ((sc-ec_data_res = bus_alloc_resource(sc-ec_dev, SYS_RES_IOPORT,
sc-ec_data_rid,
0, ~0, 1, RF_ACTIVE)) == NULL) {
@@ -571,7 +577,6 @@
if ((Address 0xFF) || (width % 8 != 0) || (Value == NULL) || (Context == NULL))
return_ACPI_STATUS(AE_BAD_PARAMETER);
-
switch (Function) {
case ACPI_READ:
EcRequest.Command = EC_COMMAND_READ;
@@ -592,6 +597,8 @@
/*
* Perform the transaction.
*/
+if(width 16)
+ EcBurstEnable(sc);
for (i = 0; i width; i += 8) {
if (Function == ACPI_READ)
EcRequest.Data = 0;
@@ -603,6 +610,10 @@
if (++EcRequest.Address == 0)
return_ACPI_STATUS(AE_BAD_PARAMETER);
}
+if(sc-ec_burst)
+ EcBurstDisable(sc);
+if(Status != AE_OK)
+ printf(%x %d\n, (UINT32) Address, width);
return_ACPI_STATUS(Status);
}
@@ -610,7 +621,7 @@
* Wait for an event interrupt for a specific condition.
*/
static ACPI_STATUS
-EcWaitEventIntr(struct acpi_ec_softc *sc, EC_EVENT Event)
+EcWaitEventIntr(struct acpi_ec_softc *sc, EC_EVENT Event, int poll)
{
EC_STATUS EcStatus;
inti;
@@ -618,9 +629,7 @@
ACPI_FUNCTION_TRACE_U32((char *)(uintptr_t)__func__, (UINT32)Event);
/* XXX this should test whether interrupts are available some other way */
-#ifdef ACPI_EC_EVENT_DRIVEN
-if(cold)
-#endif
+if(cold||sc-ec_burst|| poll)
return_ACPI_STATUS(EcWaitEvent(sc, Event));
if (!EcIsLocked(sc))
@@ -776,72 +785,121 @@
return(Status);
}
-
static ACPI_STATUS
-CURRENT freezes on boot - Thinkpad T23
I thought I'd take the plunge and jump from -STABLE to -CURRENT on my IBM ThinkPad T23. Sadly, there is no love from -CURRENT. I was able to rebuild world and create a kernel, but when I boot with the new kernel, it freezes. Specifically, the boot loader loads the kernel, and the spinning baton moves one notch and halts; a few seconds later the cursor changes from an underscore to a full block and then I pronounce the system hung. What tools are at my disposal to help figure out what's going on? I tried 'boot -v' but that showed nothing; I'm not sure if DDB will help me out. Any suggestions? -- Matthew Emmerton || [EMAIL PROTECTED] GSI Computer Services || http://www.gsicomp.on.ca To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
i386 tinderbox failure
-- Rebuilding the temporary build tree -- stage 1: bootstrap tools -- stage 2: cleaning up the object tree -- stage 2: rebuilding the object tree -- stage 2: build tools -- stage 3: cross tools -- stage 4: populating /home/des/tinderbox/i386/obj/local0/scratch/des/src/i386/usr/include -- stage 4: building libraries -- === lib/libkvm /local0/scratch/des/src/lib/libkvm/kvm_proc.c: In function `kvm_proclist': /local0/scratch/des/src/lib/libkvm/kvm_proc.c:334: structure has no member named `ke_slptime' *** Error code 1 Stop in /local0/scratch/des/src/lib/libkvm. *** Error code 1 Stop in /local0/scratch/des/src. *** Error code 1 Stop in /local0/scratch/des/src. *** Error code 1 Stop in /local0/scratch/des/src. *** Error code 1 Stop in /local0/scratch/des/src. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Ports depending on forbidden compat3x?
On 2002-08-30 08:27 +, Craig Rodrigues wrote: [snip] The install failed because of the following: Checksum OK for jre1.1.8i_ELF.V1999-11-9.tar.gz. === jre-1.1.8 depends on shared library: c.3 - not found ===Verifying install for c.3 in /usr/ports/misc/compat3x === compat3x-i386-5.0.20020219 is forbidden: FreeBSD-SA-02:28.resolv - buffer overflow in resolver in libc. See also PR ports/42138. -- Munish Chopra To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
