Re: Vinum R5
On Sat, Mar 15, 2003 at 12:02:23PM +1030, Greg 'groggy' Lehey [EMAIL PROTECTED] wrote: -current, system did panic everytime at the end of initialisation of parity (raidctl -iv raid?). So I used the raidframe patch for -stable at http://people.freebsd.org/~scottl/rf/2001-08-28-RAIDframe-stable.diff.gz Had to do some patching by hand, but otherwise works well. I don't think that problems with RAIDFrame are related to these problems with Vinum. I seem to remember a commit to the head branch recently (in the last 12 months) relating to the problem you've seen. I forget exactly where it went (it wasn't from me), and in cursory searching I couldn't find it. It's possible that it hasn't been MFC'd, which would explain your problem. If you have a 5.0 machine, it would be interesting to see if you can reproduce it there. Yes, yes, the whole raidframe story was meant as information about the conditions I did the raidframe vs. Vinum testing on. Nothing to do with Vinum, besides that raidframe works and Vinum does not. Will it suffice to switch off power for one disk to simulate more real-world disk failure? Are there any hidden pitfalls for failing and restoring operation of non-hotswap disks? I don't think so. It was more thinking aloud than anything else. As I said above, this is the way I tested things in the first place. Ok, I'll try to simulate the disk failure by switching off the power, then. Thanks -- Vallo Kallaste To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
mkioctls failed on SMP system?
Hi, On an SMP system I cvsup-ped to the latest kernel source, made the new kernel (the usual config, make depend, make, make modules, make install) and after I rebooted I tried make buildworld. On most systems I upgraded this worked just fine, except for the single SMP system I have: it seems that mkioctls takes ages, however the same command runs within the minute on another (with weaker CPU) system. I don't monitor the building process closely (so I don't know if the system really ran out of space), but I get the following error: === usr.bin/kdump sh /vol4/src/usr.bin/kdump/mkioctls /usr/obj/vol4/src/i386/usr/include ioctl.c /vol4/src/usr.bin/kdump/mkioctls: Out of space *** Error code 2 I can hack around this, and copy an ioctl.c from another system, but I guess that's not the way to go ;-) Is this a known problem? Paul P.S. I rebooted my machine between the make install of the kernel and the make buildworld - is that necessary? It would be nicer if the system rebooted just once with the new install... I don't know how the buildworld process depends on the kernel installed... To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Clock running double time
On Fri, Mar 14, 2003 at 11:14:51PM -0800, [EMAIL PROTECTED] wrote: Has anyone ever seen this? My clock is running double time, that is, each second it advances two seconds. Needless to say, ntpd can't sync up with any servers. This has been reported several times (searching the mailinglist archives gives great results): http://docs.freebsd.org/cgi/getmsg.cgi?fetch=369488+0+archive/2003/freebsd-current/20030223.freebsd-current http://docs.freebsd.org/cgi/getmsg.cgi?fetch=811469+0+archive/2003/freebsd-current/20030216.freebsd-current http://docs.freebsd.org/cgi/getmsg.cgi?fetch=884815+0+archive/2003/freebsd-current/20030126.freebsd-current Read up on those threads and you'll hopefully get it fixed. -- Morten Rodal pgp0.pgp Description: PGP signature
Re: mkioctls failed on SMP system?
/vol4/src/usr.bin/kdump/mkioctls: Out of space mabye it's just me... but you may wish to check the space left avail on the drive you're compiling on... it clearly states Out of space. ? Just a wild guess though... Regards, Nick H. [EMAIL PROTECTED] - Original Message - From: Paul Dekkers [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Saturday, March 15, 2003 2:56 AM Subject: mkioctls failed on SMP system? : Hi, : : On an SMP system I cvsup-ped to the latest kernel source, made the new : kernel (the usual config, make depend, make, make modules, make install) : and after I rebooted I tried make buildworld. On most systems I upgraded : this worked just fine, except for the single SMP system I have: it seems : that mkioctls takes ages, however the same command runs within the : minute on another (with weaker CPU) system. I don't monitor the building : process closely (so I don't know if the system really ran out of space), : but I get the following error: : : === usr.bin/kdump : sh /vol4/src/usr.bin/kdump/mkioctls /usr/obj/vol4/src/i386/usr/include : ioctl.c : /vol4/src/usr.bin/kdump/mkioctls: Out of space : *** Error code 2 : : I can hack around this, and copy an ioctl.c from another system, but I : guess that's not the way to go ;-) : : Is this a known problem? : : Paul : : P.S. I rebooted my machine between the make install of the kernel and : the make buildworld - is that necessary? It would be nicer if the system : rebooted just once with the new install... I don't know how the : buildworld process depends on the kernel installed... : : : : To Unsubscribe: send mail to [EMAIL PROTECTED] : with unsubscribe freebsd-current in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: can't boot with twe anymore.
In message [EMAIL PROTECTED], Alfred Perlstein writes:
Poul-Henning you promised me a patch two nights ago within a couple
of hours It's now going on the 36th hour since.
Yeah, well, I didn't calculate with being hit by influenze :-(
Can you try this one:
Index: twe_compat.h
===
RCS file: /home/ncvs/src/sys/dev/twe/twe_compat.h,v
retrieving revision 1.6
diff -u -r1.6 twe_compat.h
--- twe_compat.h8 Mar 2003 08:01:30 - 1.6
+++ twe_compat.h15 Mar 2003 09:48:46 -
@@ -166,7 +166,7 @@
# define TWE_BIO_LENGTH(bp)(bp)-bio_bcount
# define TWE_BIO_LBA(bp) (bp)-bio_pblkno
# define TWE_BIO_SOFTC(bp) (bp)-bio_disk-d_drv1
-# define TWE_BIO_UNIT(bp) (bp)-bio_disk-d_unit
+# define TWE_BIO_UNIT(bp) (((struct twed_softc
*)TWE_BIO_SOFTC(bp))-twed_drive-td_unit)
# define TWE_BIO_SET_ERROR(bp, err)do { (bp)-bio_error = err; (bp)-bio_flags |=
BIO_ERROR;} while(0)
# define TWE_BIO_HAS_ERROR(bp) ((bp)-bio_flags BIO_ERROR)
# define TWE_BIO_RESID(bp) (bp)-bio_resid
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
January-February 2003 FreeBSD Bi-Monthly Status Report
January-February 2003 Status Report Introduction: Another busy two months have passed in the FreeBSD project. With 5.0 released, attention is focusing on making it faster via more fine-grained locking, adding more high-end features like large memory (PAE) support for i386, and further progress on many other projects. FreeBSD 5.1 is expected to ship in late May or early June, with 5.2 following at the end of summer. A roadmap for the push to 5-STABLE is available at [2]http://www.freebsd.org/doc/en/articles/5-roadmap. Although the 5.x series isn't expected to fully stabilize until the 5.2 release, 5.1 promises to be an exciting release and a significant improvement over 5.0 in terms of speed and stability. Not to be forgotten, FreeBSD 4.8, the latest in the 4-STABLE series, is nearing release. Lots of last minute work is going into to it to deliver features like XFree86 4.3.0, Intel HyperThreading(tm) support, and of course many more bug fixes. Don't forget to support the FreeBSD vendors and developers by buying a copy of the CD set when it comes out!. Thanks, Scott Long, Robert Watson Bluetooth stack for FreeBSD (Netgraph implementation) URL: http://www.geocities.com/m_evmenkin/ URL: http://bluez.sf.net URL: http://sourceforge.net/projects/openobex/ Contact: Maksim Yevmenkin [EMAIL PROTECTED] I'm very pleased to announce that another release is available for download at http://www.geocities.com/m_evmenkin/ngbt-fbsd-20030305.tar.gz This release features new in-kernel RFCOMM implementation that provides SOCK_STREAM sockets interface. This makes old user-space RFCOMM daemon obsolete. People should not use old user-space RFCOMM daemon any longer. The release features new RFCOMM PPP daemon that supports DUN and LAN profiles. Note: PPP patch (support for chat scripts in -direct mode) is required for DUN support. Look for it in the mailing list archive or contact me directly. People with Bluetooth enabled cell phones can now use them to access Internet. The Bluetooth sockets layer has been cleaned up. People should not see any WITNESS complains with new code. Locking issues have been revisited and code in much better shape now, although it probably is not 100% SMP ready just yet. The code should work on SMP system anyway because sockets layer is still under Giant. The simple OBEX server and client (based on OpenOBEX library) is complete. OBEX File Push and OBEX File Transfer profiles work and have been tested with Sony Ericsson T68i cell phone and Bluetooth 3COM stack on Windows2K. It is now possible to send pictures, address book and calendar entries from the cell phone via Bluetooth. Minor bug in OpenOBEX library has been fixed and OPEX Put-Empty command now works. Due to changes in API userland tools must be in sync with the kernel. People should install new include files, recompile and reinstall all userland tools as part of upgrade. I'm sorry about that. _ BSDCon 2003 URL: http://www.usenix.org/events/bsdcon03/cfp/ Contact: Gregory Shapiro [EMAIL PROTECTED] The BSDCon 2003 Program Committee invites you to contribute original and innovative papers on topics related to BSD-derived systems and the Open Source world. Topics of interest include but are not limited to: * Embedded BSD application development and deployment * Real world experiences using BSD systems * Using BSD in a mixed OS environment * Comparison with non-BSD operating systems; technical, practical, licensing (GPL vs. BSD) * Tracking open source development on non-BSD systems * BSD on the desktop * I/O subsystem and device driver development * SMP and kernel threads * Kernel enhancements * Internet and networking services * Security * Performance analysis and tuning * System administration * Future of BSD Submissions in the form of extended abstracts are due by April 1, 2003. Be sure to review the extended abstract expectations before submitting. Selection will be based on the quality of the written submission and whether the work is of interest to the community. We look forward to receiving your submissions! _ Buffer Cache lockdown Contact: Jeff Roberson [EMAIL PROTECTED] Most of the file system buffer cache has been reviewed and protected. The vnode interlock was extended to cover some buffer flag fields so that a seperate interlock was not required. The global buffer queue data structures were locked and counters were converted to atomic ops. The BUF_*LOCK functions grew an interlock argument so that buffers could be safely removed from the vnode clean and dirty lists. The lockmgr lock
Re: can't boot with twe anymore.
In message [EMAIL PROTECTED], Alfred Perlstein writes:
Poul-Henning you promised me a patch two nights ago within a couple
of hours It's now going on the 36th hour since.
Ok, 2nd try, this even compiles:
Index: twe_compat.h
===
RCS file: /home/ncvs/src/sys/dev/twe/twe_compat.h,v
retrieving revision 1.6
diff -u -r1.6 twe_compat.h
--- twe_compat.h8 Mar 2003 08:01:30 - 1.6
+++ twe_compat.h15 Mar 2003 09:58:06 -
@@ -166,7 +166,7 @@
# define TWE_BIO_LENGTH(bp)(bp)-bio_bcount
# define TWE_BIO_LBA(bp) (bp)-bio_pblkno
# define TWE_BIO_SOFTC(bp) (bp)-bio_disk-d_drv1
-# define TWE_BIO_UNIT(bp) (bp)-bio_disk-d_unit
+# define TWE_BIO_UNIT(bp) *(int *)(bp-bio_driver1)
# define TWE_BIO_SET_ERROR(bp, err)do { (bp)-bio_error = err; (bp)-bio_flags |=
BIO_ERROR;} while(0)
# define TWE_BIO_HAS_ERROR(bp) ((bp)-bio_flags BIO_ERROR)
# define TWE_BIO_RESID(bp) (bp)-bio_resid
Index: twe_freebsd.c
===
RCS file: /home/ncvs/src/sys/dev/twe/twe_freebsd.c,v
retrieving revision 1.24
diff -u -r1.24 twe_freebsd.c
--- twe_freebsd.c 8 Mar 2003 08:01:30 - 1.24
+++ twe_freebsd.c 15 Mar 2003 09:57:24 -
@@ -607,6 +607,7 @@
debug_called(4);
+bp-bio_driver1 = sc-twed_drive-td_unit;
TWED_BIO_IN;
/* bogus disk? */
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Top weirdness.
Check these out: http://chat.carleton.ca/~creyenga/1sttime.JPG http://chat.carleton.ca/~creyenga/again.JPG Pretty strange, my normally-aspirated computer is somehow using 168% of cpu. boss# uname -a FreeBSD boss.sewer.org 5.0-CURRENT FreeBSD 5.0-CURRENT #0: Fri Mar 7 01:49:18 EST 2003 [EMAIL PROTECTED]:/usr/obj/usr/s/run/src/sys/BOSSKERN i386 Using SCHED_4BSD. -Craig To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
() REFILL.CO.KR @
Title: ´ëÇѹα¹ ´ëÇ¥ ¸®ÇÊ»çÀÌÆ® :: Refill.co.kr Á¤º¸Åë½ÅºÎ ±Ç°í »çÇ× ¹ý·ü Á¦ 50Á¶¿¡ ÀÇ°ÅÇÏ¿© Á¦¸ñ¿¡ (±¤°í)¶ó°í Ç¥±âÇÑ ±¤°í¸ÞÀÏÀ̸ç, ±ÍÇÏÀÇ ¸ÞÀÏÁÖ¼Ò´Â À¥ ¼ÇÎÁß ¾Ë°Ô µÈ °ÍÀ̸ç, eMail ÁÖ¼Ò ¿Ü¿¡ ±ÍÇÏÀÇ ¾î¶°ÇÑ Á¤º¸µµ °¡Áö°í ÀÖÁö ¾ÊÀ¸´Ï ¾È½ÉÇÏ½Ã±æ ¹Ù¶ø´Ï´Ù. º» ¸ÞÀÏÀº ¹ß¼ÛÀü¿ë ¸ÞÀÏÀÓÀ¸·Î, ¿øÄ¡ ¾ÊÀ¸½Ã¸é [¼ö½Å°ÅºÎ] ¹öÆ°À» Click ÇØ ÁÖ¼¼¿ä. If you would like to be removed from any of our distribution lists, please click 'REFUSE'. It will be handled promptly. Thank you. [REFUSE] ¡Ø °í°´ ¼ºñ½º ¹®ÀÇ : 02-3281- Copyright 1991-2002. Futech co,.Ltd. All right reserved. ¡Iì¹» ®&Þ±éݨ¥¶Ý¢jçH:+éì¹» ®&Þ~·nÇ\ººÞا¶¡Ü¨~Ø^ë,j
Re: mkioctls failed on SMP system?
Ah, I should have mentioned that: there is about 8 GB available on /vol4, on /usr there is 3 GB, / 300 MB, so I don't think it's worth trying on another disk... BTW, It looks like the problem is in the ioctl_includes=`` - it never gets any further. (Checked with echo's.) Paul Nick H. wrote: /vol4/src/usr.bin/kdump/mkioctls: Out of space mabye it's just me... but you may wish to check the space left avail on the drive you're compiling on... it clearly states Out of space. ? Just a wild guess though... Regards, Nick H. [EMAIL PROTECTED] - Original Message - From: Paul Dekkers [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Saturday, March 15, 2003 2:56 AM Subject: mkioctls failed on SMP system? : Hi, : : On an SMP system I cvsup-ped to the latest kernel source, made the new : kernel (the usual config, make depend, make, make modules, make install) : and after I rebooted I tried make buildworld. On most systems I upgraded : this worked just fine, except for the single SMP system I have: it seems : that mkioctls takes ages, however the same command runs within the : minute on another (with weaker CPU) system. I don't monitor the building : process closely (so I don't know if the system really ran out of space), : but I get the following error: : : === usr.bin/kdump : sh /vol4/src/usr.bin/kdump/mkioctls /usr/obj/vol4/src/i386/usr/include : ioctl.c : /vol4/src/usr.bin/kdump/mkioctls: Out of space : *** Error code 2 : : I can hack around this, and copy an ioctl.c from another system, but I : guess that's not the way to go ;-) : : Is this a known problem? : : Paul : : P.S. I rebooted my machine between the make install of the kernel and : the make buildworld - is that necessary? It would be nicer if the system : rebooted just once with the new install... I don't know how the : buildworld process depends on the kernel installed... : : : : To Unsubscribe: send mail to [EMAIL PROTECTED] : with unsubscribe freebsd-current in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: ENOMEM error diagnosis?
Lucky Green (Fri, Mar 14, 2003 at 06:40:58PM -0800) wrote:
I am seeing a lot of crashes of GBDE, causing ENOMEM errors to scroll
rapidly on the console. Whenever this happens, the server becomes
unresponsive to keyboard or any other input and has to be power cycled.
Is there some debug setting that I can set which would help diagnose the
problem further? This is on a minimally-loaded test machine with no
other users and no significant load from any services.
I stumbled upon this problem when I was messing around with the
swapoff() system call and /dev/md. If you do the following:
# swapoff all-swap-devices (one after another...
# mdconfig -a -t swap -s 30M -u 3
# newfs /dev/md0
(nice unkillable loop)
So, doing some research indicates that one way of fixing this
problem was to detect if swap was available at all, in the
md{start,done}_swap() routines, but not sure if that is the best
fix.
The ENOMEM error occurs in geom_io.c:g_io_deliver(). I have not
familiarized myself with the GEOM code yet, but I could get a
stack trace by just shoving panic() into g_io_deliver(). If you
are running X or some sort of window system, you will not be
able to use it, as Lucky Green said, it will be just hang.
Going into DDB will not help because it hasn't crashed, and even
doing so, will just give you a trace of the fork_trampoline(),
ithd_loop() stuff... i.e. nothing which helps with the problem.
The error looks like:
ENOMEM (0xsome-addr) on (0xsome-addr)... in my case.
Cheers.
-- Hiten
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: ENOMEM error diagnosis?
In message [EMAIL PROTECTED], Lucky Green writes: I am seeing a lot of crashes of GBDE, causing ENOMEM errors to scroll rapidly on the console. Whenever this happens, the server becomes unresponsive to keyboard or any other input and has to be power cycled. Is there some debug setting that I can set which would help diagnose the problem further? This is on a minimally-loaded test machine with no other users and no significant load from any services. Make sure you have rev 1.9 of src/sys/geom/bde/g_bde_crypt.c I hadn't done my math and before that rev gbde would request very large lumps of ram from malloc(9). -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
SiS5591(?) ATA
Hi, I've upgraded to -CURRENT from -STABLE yesterday. But something strange with ATA. It can't be used in UDMA100 mode. In boot message, ... pci0: mass storage, ATA at device 2.5 (no driver attached) ... ad0: 78533MB IC35L080AVVA07-0 [159560/16/63] at ata0-master PIO4 ad1: 39266MB IC35L040AVER07-0 [79780/16/63] at ata0-slave PIO4 acd0: DVD-R MATSHITADVD-RAM SW-9571 at ata1-master PIO4 ... It works in UDMA100 with -STABLE, ... atapci0: SiS 5591 ATA100 controller port 0xff00-0xff0f at device 2.5 on pci0 ... ad0: 78533MB IC35L080AVVA07-0 [159560/16/63] at ata0-master UDMA100 ad1: 39266MB IC35L040AVER07-0 [79780/16/63] at ata0-slave UDMA100 acd0: DVD-R MATSHITADVD-RAM SW-9571 at ata1-master UDMA66 ... Here is pciconf -lv output # pciconf -lv [EMAIL PROTECTED]:0:0: class=0x06 card=0x chip=0x06501039 rev=0x01 hdr=0x00 vendor = 'Silicon Integrated Systems (SiS)' device = 'SiS 650 Host-to-PCI Bridge' class= bridge subclass = HOST-PCI [EMAIL PROTECTED]:1:0: class=0x060400 card=0x chip=0x00011039 rev=0x00 hdr=0x01 vendor = 'Silicon Integrated Systems (SiS)' device = 'SiS 530 Virtual PCI-to-PCI bridge (AGP)' class= bridge subclass = PCI-PCI [EMAIL PROTECTED]:2:0: class=0x060100 card=0x chip=0x00081039 rev=0x00 hdr=0x00 vendor = 'Silicon Integrated Systems (SiS)' device = 'SiS85C503/5513 PCI to ISA Bridge (LPC Bridge)' class= bridge subclass = PCI-ISA [EMAIL PROTECTED]:2:2: class=0x0c0310 card=0x70011039 chip=0x70011039 rev=0x07 hdr=0x00 vendor = 'Silicon Integrated Systems (SiS)' device = 'SiS5597/8 Universal Serial Bus Controller' class= serial bus subclass = USB [EMAIL PROTECTED]:2:3: class=0x0c0310 card=0x70011039 chip=0x70011039 rev=0x07 hdr=0x00 vendor = 'Silicon Integrated Systems (SiS)' device = 'SiS5597/8 Universal Serial Bus Controller' class= serial bus subclass = USB [EMAIL PROTECTED]:2:5: class=0x010180 card=0x55131039 chip=0x55131039 rev=0xd0 hdr=0x00 vendor = 'Silicon Integrated Systems (SiS)' device = 'SiS5513 EIDE Controller (A,B step)' class= mass storage subclass = ATA [EMAIL PROTECTED]:2:7: class=0x040100 card=0x030013f6 chip=0x70121039 rev=0xa0 hdr=0x00 vendor = 'Silicon Integrated Systems (SiS)' device = 'SiS7012 PCI Audio Accelerator' class= multimedia subclass = audio [EMAIL PROTECTED]:3:0: class=0x02 card=0x09001039 chip=0x09001039 rev=0x90 hdr=0x00 vendor = 'Silicon Integrated Systems (SiS)' device = 'SiS900 Fast Ethernet/Home Networking Ctrlr' class= network subclass = ethernet What's wrong ? Regards, To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
crash: bremfree: removing a buffer not on a queue
Hi,
My -CURRENT(2003/03/12) box crashes while using linux-mozilla.
# gdb -k kernel.debug.0 vmcore.0
GNU gdb 5.2.1 (FreeBSD)
Copyright 2002 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type show copying to see the conditions.
There is absolutely no warranty for GDB. Type show warranty for details.
This GDB was configured as i386-undermydesk-freebsd...
panic: bremfree: removing a buffer not on a queue
panic messages:
---
panic: bwrite: buffer is not busy???
syncing disks, buffers remaining... panic: bremfree: removing a buffer not on a queue
Uptime: 12h48m16s
Dumping 639 MB
ata0: resetting devices ..
done
[CTRL-C to abort] 16 32 48 64 80 96[CTRL-C to abort] [CTRL-C to abort] [CTRL-C to
abort] 112 128 144 160 176 192 208 224 240 256 272 288 304 320 336 352 368 384 400
416 432 448 464 480 496 512 528 544 560 576 592 608 624
---
#0 doadump () at ../../../kern/kern_shutdown.c:239
239 dumping++;
(kgdb) bt
#0 doadump () at ../../../kern/kern_shutdown.c:239
#1 0xc039bf4a in boot (howto=260) at ../../../kern/kern_shutdown.c:371
#2 0xc039c1b3 in panic () at ../../../kern/kern_shutdown.c:542
#3 0xc03e0130 in bremfreel (bp=0xd1955320) at ../../../kern/vfs_bio.c:630
#4 0xc03e0042 in bremfree (bp=0x0) at ../../../kern/vfs_bio.c:612
#5 0xc03e20e0 in vfs_bio_awrite (bp=0x0) at ../../../kern/vfs_bio.c:1682
#6 0xc04fb61a in ffs_fsync (ap=0xedd138b8) at ../../../ufs/ffs/ffs_vnops.c:257
#7 0xc04fa6c7 in ffs_sync (mp=0xc5565800, waitfor=2, cred=0xc1c31e80,
td=0xc064f4c0) at vnode_if.h:612
#8 0xc03f6f9b in sync (td=0xc064f4c0, uap=0x0)
at ../../../kern/vfs_syscalls.c:138
#9 0xc039bb0c in boot (howto=256) at ../../../kern/kern_shutdown.c:280
#10 0xc039c1b3 in panic () at ../../../kern/kern_shutdown.c:542
#11 0xc03e05b2 in bwrite (bp=0xd1857e50) at ../../../kern/vfs_bio.c:795
#12 0xc03e0f2c in bawrite (bp=0x0) at ../../../kern/vfs_bio.c:1138
#13 0xc03e8f8f in cluster_wbuild (vp=0xc5f2aa44, size=16384, start_lbn=51,
len=2) at ../../../kern/vfs_cluster.c:966
#14 0xc03e858f in cluster_write (bp=0xd1955320, filesize=884736, seqcount=4)
at ../../../kern/vfs_cluster.c:566
#15 0xc04fc23c in ffs_write (ap=0xedd13bc4) at ../../../ufs/ffs/ffs_vnops.c:728
#16 0xc03ff261 in vn_write (fp=0xc5919a8c, uio=0xedd13c70,
active_cred=0xc5a3a780, flags=0, td=0xc59a7b40) at vnode_if.h:417
#17 0xc03bf198 in dofilewrite (td=0xc59a7b40, fp=0xc5919a8c, fd=0,
buf=0x9f2fb90, nbyte=0, offset=0, flags=0) at file.h:239
#18 0xc03befd9 in write (td=0xc59a7b40, uap=0xedd13d10)
at ../../../kern/sys_generic.c:329
#19 0xc05607da in syscall (frame=
{tf_fs = 153944111, tf_es = 47, tf_ds = -1078001617, tf_edi = 166919056, tf_esi
= 512, tf_ebp = -1077940260, tf_isp = -305054348, tf_ebx = 31, tf_edx = 512, tf_ecx =
166919056, tf_eax = 4, tf_trapno = 22, tf_err = 2, tf_eip = 677762996, tf_cs = 31,
tf_eflags = 662, tf_esp = -1077940308, tf_ss = 47})
at ../../../i386/i386/trap.c:1030
#20 0xc054f49d in Xint0x80_syscall () at {standard input}:138
---Can't read userspace from dump, or kernel process---
Regards,
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
crash: lockmgr: locking against myself
Hi, My -CURRENT(2003/03/14) box crashes when I tried to mount UDF(DVD-RAM). # mount -t udf -o ro /dev/acd0 /dvdram Here is the stack trace, # gdb -k kernel.debug.0 vmcore.0 GNU gdb 5.2.1 (FreeBSD) Copyright 2002 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type show copying to see the conditions. There is absolutely no warranty for GDB. Type show warranty for details. This GDB was configured as i386-undermydesk-freebsd... panic: (fmt null) panic messages: --- panic: lockmgr: locking against myself syncing disks, buffers remaining... 3848 3848 Copyright (c) 1992-2003 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 5.0-CURRENT-20030314-JPSNAP #1: Sat Mar 15 18:59:26 JST 2003 [EMAIL PROTECTED]:/usr/src/sys/i386/compile/FAITHIA Preloaded elf kernel /boot/kernel/kernel at 0xc0802000. Preloaded elf module /boot/kernel/acpi.ko at 0xc08020a8. Timecounter i8254 frequency 1193182 Hz Timecounter TSC frequency 282900 Hz CPU: Intel(R) Pentium(R) 4 CPU 2.00GHz (2000.08-MHz 686-class CPU) Origin = GenuineIntel Id = 0xf24 Stepping = 4 Features=0x3febf9ffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,MTRR,PGE,MCA,CMOV,P AT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM real memory = 536805376 (511 MB) avail memory = 512778240 (489 MB) Allocating major#253 to net Allocating major#252 to pci Pentium Pro MTRR support enabled npx0: math processor on motherboard npx0: INT 16 interface acpi0: AMIINT SiS645XX on motherboard ACPI-0625: *** Info: GPE Block0 defined as GPE0 to GPE15 ACPI-0625: *** Info: GPE Block1 defined as GPE16 to GPE31 pcibios: BIOS version 2.10 Using $PIR table, 8 entries at 0xc00f7ae0 acpi0: power button is handled as a fixed feature programming model. Timecounter ACPI-fast frequency 3579545 Hz :acpi_timer0: 24-bit timer at 3.579545MHz port 0x808-0x80b on acpi0 acpi_cpu0: CPU port 0x530-0x537 on acpi0 acpi_button0: Power Button on acpi0 pcib0: ACPI Host-PCI bridge port 0xcf8-0xcff on acpi0 pci0: ACPI PCI bus on pcib0 agp0: SIS Generic host to PCI bridge mem 0xe000-0xe3ff at device 0.0 on pci0 pcib1: PCIBIOS PCI-PCI bridge at device 1.0 on pci0 pci1: PCI bus on pcib1 pci1: display, VGA at device 0.0 (no driver attached) isab0: PCI-ISA bridge at device 2.0 on pci0 isa0: ISA bus on isab0 ohci0: SiS 5571 USB controller mem 0xdfffe000-0xdfffefff irq 11 at device 2.2 on pci0 usb0: OHCI version 1.0, legacy support usb0: SiS 5571 USB controller on ohci0 usb0: USB revision 1.0 uhub0: SiS OHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 3 ports with 3 removable, self powered ohci1: SiS 5571 USB controller mem 0xd000-0xdfff irq 5 at device 2.3 on pci0 usb1: OHCI version 1.0, legacy support usb1: SiS 5571 USB controller on ohci1 usb1: USB revision 1.0 uhub1: SiS OHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub1: 3 ports with 3 removable, self powered pci0: mass storage, ATA at device 2.5 (no driver attached) pcm0: SiS 7012 port 0xd800-0xd87f,0xdc00-0xdcff irq 11 at device 2.7 on pci0 pcm0: C-Media Electronics CMI9738 AC97 Codec sis0: SiS 900 10/100BaseTX port 0xd400-0xd4ff mem 0xdfff9000-0xdfff9fff irq 5 at device 3.0 on pci0 sis0: Ethernet address: 00:07:95:c0:de:e2 miibus0: MII bus on sis0 rlphy0: RTL8201L 10/100 media interface on miibus0 rlphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto em0: Intel(R) PRO/1000 Network Connection, Version - 1.4.10 port 0xd000-0xd03f mem 0xdff8-0xdff9,0xdffa-0xdffb irq 11 at device 9.0 on pci0 em0: Speed:100 Mbps Duplex:Full fxp0: Intel 82557/8/9 EtherExpress Pro/100(B) Ethernet port 0xcc00-0xcc3f mem 0xdff4-0xdff5,0xdfff8000-0xdfff8fff irq 5 at device 11.0 on pci0 fxp0: Ethernet address 00:02:b3:a6:83:2d inphy0: i82555 10/100 media interface on miibus1 inphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto acpi_button1: Sleep Button on acpi0 atkbdc0: Keyboard controller (i8042) port 0x64,0x60 irq 1 on acpi0 atkbd0: AT Keyboard flags 0x1 irq 1 on atkbdc0 kbd0 at atkbd0 psm0: PS/2 Mouse irq 12 on atkbdc0 psm0: model IntelliMouse Explorer, device ID 4 fdc0: cmd 3 failed at out byte 1 of 3 sio0 port 0x3f8-0x3ff irq 4 on acpi0 sio0: type 16550A sio1 port 0x2f8-0x2ff irq 3 on acpi0 sio1: type 16550A ppc0 port 0x778-0x77b,0x378-0x37f irq 7 drq 3 on acpi0 ppc0: Generic chipset (ECP/PS2/NIBBLE) in COMPATIBLE mode ppc0: FIFO with 16/16/16 bytes threshold plip0: PLIP network interface on ppbus0 lpt0: Printer on ppbus0 lpt0: Interrupt-driven port ppi0: Parallel I/O on ppbus0 fdc0: cmd 3 failed at out byte 1 of 3 orm0: Option ROMs at iomem 0xcf000-0xd4fff,0xcd800-0xcefff,0xcc000-0xcd7ff,0xc-0xcbfff on isa0 pmtimer0 on isa0 ata0 at port 0x3f6,0x1f0-0x1f7 irq 14 on isa0 ata1 at port 0x376,0x170-0x177 irq 15 on isa0 fdc0: cannot
Re: can't boot with twe anymore.
* Poul-Henning Kamp [EMAIL PROTECTED] [030315 01:59] wrote:
In message [EMAIL PROTECTED], Alfred Perlstein writes:
Poul-Henning you promised me a patch two nights ago within a couple
of hours It's now going on the 36th hour since.
Ok, 2nd try, this even compiles:
That looks like it might work, but doesn't it work around instead
of fix the problem you found where twe does sparse unit assignment?
Index: twe_compat.h
===
RCS file: /home/ncvs/src/sys/dev/twe/twe_compat.h,v
retrieving revision 1.6
diff -u -r1.6 twe_compat.h
--- twe_compat.h 8 Mar 2003 08:01:30 - 1.6
+++ twe_compat.h 15 Mar 2003 09:58:06 -
@@ -166,7 +166,7 @@
# define TWE_BIO_LENGTH(bp) (bp)-bio_bcount
# define TWE_BIO_LBA(bp) (bp)-bio_pblkno
# define TWE_BIO_SOFTC(bp) (bp)-bio_disk-d_drv1
-# define TWE_BIO_UNIT(bp)(bp)-bio_disk-d_unit
+# define TWE_BIO_UNIT(bp)*(int *)(bp-bio_driver1)
# define TWE_BIO_SET_ERROR(bp, err) do { (bp)-bio_error = err; (bp)-bio_flags |=
BIO_ERROR;} while(0)
# define TWE_BIO_HAS_ERROR(bp) ((bp)-bio_flags BIO_ERROR)
# define TWE_BIO_RESID(bp) (bp)-bio_resid
Index: twe_freebsd.c
===
RCS file: /home/ncvs/src/sys/dev/twe/twe_freebsd.c,v
retrieving revision 1.24
diff -u -r1.24 twe_freebsd.c
--- twe_freebsd.c 8 Mar 2003 08:01:30 - 1.24
+++ twe_freebsd.c 15 Mar 2003 09:57:24 -
@@ -607,6 +607,7 @@
debug_called(4);
+bp-bio_driver1 = sc-twed_drive-td_unit;
TWED_BIO_IN;
/* bogus disk? */
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
--
-Alfred Perlstein [EMAIL PROTECTED]
'Instead of asking why a piece of software is using 1970s technology,
start asking why software is ignoring 30 years of accumulated wisdom.'
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: can't boot with twe anymore.
In message [EMAIL PROTECTED], Alfred Perlstein writes: * Poul-Henning Kamp [EMAIL PROTECTED] [030315 01:59] wrote: In message [EMAIL PROTECTED], Alfred Perlstein writes: Poul-Henning you promised me a patch two nights ago within a couple of hours It's now going on the 36th hour since. Ok, 2nd try, this even compiles: That looks like it might work, but doesn't it work around instead of fix the problem you found where twe does sparse unit assignment? It should make the driver work exactly like before, which IMO was slightly bogus, if that was what you were asking :-) -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: can't boot with twe anymore.
* Poul-Henning Kamp [EMAIL PROTECTED] [030315 04:09] wrote: In message [EMAIL PROTECTED], Alfred Perlstein writes: * Poul-Henning Kamp [EMAIL PROTECTED] [030315 01:59] wrote: In message [EMAIL PROTECTED], Alfred Perlstein writes: Poul-Henning you promised me a patch two nights ago within a couple of hours It's now going on the 36th hour since. Ok, 2nd try, this even compiles: That looks like it might work, but doesn't it work around instead of fix the problem you found where twe does sparse unit assignment? It should make the driver work exactly like before, which IMO was slightly bogus, if that was what you were asking :-) I'm not sure I understand, but I just tested this. It works. Thanks for getting back to me and I hope you're feeling better. -- -Alfred Perlstein [EMAIL PROTECTED] 'Instead of asking why a piece of software is using 1970s technology, start asking why software is ignoring 30 years of accumulated wisdom.' To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: panic on boot (devfs_find)
On 15-Mar-2003 Bryan Liesner wrote: On Fri, 14 Mar 2003, Conrad Sabatier wrote: Now, really, am I the only one experiencing this? No, you're not. I've been unable to get a bootable kernel running for the last few days also. Booting in verbose mode, I see the last thing that occurs just before the panic is mounting root and then starting (or trying to start) /sbin/init. After an initial hang, it drops into ddb. Did it panic on devfs_find()? And, if you've seen my earlier posts, have you experienced that stuff too? Yes, exactly right. In devfs_find(). And looking back at your earlier posts, it looks like my experiences pretty much correlate with yours. -- Conrad Sabatier [EMAIL PROTECTED] - In Unix veritas To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
RE: panic on boot (devfs_find)
cheer! wilma heeft het door. guest werkt. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Conrad Sabatier Sent: zaterdag 15 maart 2003 13:22 To: Bryan Liesner Cc: [EMAIL PROTECTED] Subject: Re: panic on boot (devfs_find) On 15-Mar-2003 Bryan Liesner wrote: On Fri, 14 Mar 2003, Conrad Sabatier wrote: Now, really, am I the only one experiencing this? No, you're not. I've been unable to get a bootable kernel running for the last few days also. Booting in verbose mode, I see the last thing that occurs just before the panic is mounting root and then starting (or trying to start) /sbin/init. After an initial hang, it drops into ddb. Did it panic on devfs_find()? And, if you've seen my earlier posts, have you experienced that stuff too? Yes, exactly right. In devfs_find(). And looking back at your earlier posts, it looks like my experiences pretty much correlate with yours. -- Conrad Sabatier [EMAIL PROTECTED] - In Unix veritas To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
RE: panic on boot (devfs_find)
whoops wrong list... -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Bug Sent: zaterdag 15 maart 2003 13:25 To: Conrad Sabatier; Bryan Liesner Cc: [EMAIL PROTECTED] Subject: RE: panic on boot (devfs_find) cheer! wilma heeft het door. guest werkt. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Conrad Sabatier Sent: zaterdag 15 maart 2003 13:22 To: Bryan Liesner Cc: [EMAIL PROTECTED] Subject: Re: panic on boot (devfs_find) On 15-Mar-2003 Bryan Liesner wrote: On Fri, 14 Mar 2003, Conrad Sabatier wrote: Now, really, am I the only one experiencing this? No, you're not. I've been unable to get a bootable kernel running for the last few days also. Booting in verbose mode, I see the last thing that occurs just before the panic is mounting root and then starting (or trying to start) /sbin/init. After an initial hang, it drops into ddb. Did it panic on devfs_find()? And, if you've seen my earlier posts, have you experienced that stuff too? Yes, exactly right. In devfs_find(). And looking back at your earlier posts, it looks like my experiences pretty much correlate with yours. -- Conrad Sabatier [EMAIL PROTECTED] - In Unix veritas To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: crash: lockmgr: locking against myself
On Sat, Mar 15, 2003 at 08:27:27PM +0900, FUJITA Kazutoshi wrote: Hi, My -CURRENT(2003/03/14) box crashes when I tried to mount UDF(DVD-RAM). # mount -t udf -o ro /dev/acd0 /dvdram [...] panic: lockmgr: locking against myself [...] (kgdb) bt [...] #10 0xc039bcbb in panic (fmt=0x0) at ../../../kern/kern_shutdown.c:528 #11 0xc038e141 in lockmgr (lkp=0xc4bce1e0, flags=16973826, interlkp=0x100, td=0xc4a023c0) at ../../../kern/kern_lock.c:447 #12 0xc03e93dc in vop_stdlock (ap=0x0) at ../../../kern/vfs_default.c:304 #13 0xc03e9228 in vop_defaultop (ap=0x0) at ../../../kern/vfs_default.c:163 #14 0xc03ffbde in vn_lock (vp=0xc4bce124, flags=131074, td=0xc4a023c0) at vnode_if.h:990 #15 0xc034e45c in udf_hashins (node=0xc4bd1000) at ../../../fs/udf/udf_vnops.c:133 #16 0xc034dea4 in udf_vget (mp=0xc4ae6c00, ino=139, flags=0, vpp=0xdd0c7af4) at ../../../fs/udf/udf_vfsops.c:617 #17 0xc034db7e in udf_root (mp=0xc4b44000, vpp=0x8b) at ../../../fs/udf/udf_vfsops.c:505 It seems that udf_vget() calls udf_allocv(), which returns a locked vnode. udf_vget() then calls udf_hashins(), which tries to lock the vnode again, causing the locking against myself panic. Here's a simple untested patch to try which makes udf_allocv() return an unlocked vnode. I'm not sure whether the locking in udf_hashins() is right. Index: sys/fs/udf/udf_vnops.c === RCS file: /home/ncvs/src/sys/fs/udf/udf_vnops.c,v retrieving revision 1.24 diff -u -r1.24 udf_vnops.c --- sys/fs/udf/udf_vnops.c 3 Mar 2003 19:15:39 - 1.24 +++ sys/fs/udf/udf_vnops.c 15 Mar 2003 12:12:13 - @@ -127,10 +127,10 @@ udfmp = node-udfmp; + vn_lock(node-i_vnode, LK_EXCLUSIVE | LK_RETRY, curthread); mtx_lock(udfmp-hash_mtx); TAILQ_INSERT_TAIL(udfmp-udf_tqh, node, tq); mtx_unlock(udfmp-hash_mtx); - vn_lock(node-i_vnode, LK_EXCLUSIVE | LK_RETRY, curthread); return (0); } @@ -161,7 +161,6 @@ return (error); } - vn_lock(vp, LK_EXCLUSIVE | LK_RETRY, td); *vpp = vp; return (0); } Tim To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: SiS5591(?) ATA
Hello, I have exactly the same problem with my system (FreeBSD 5.0-CURRENT #8: Thu Mar 13 15:56:51 CET 2003). My board is a K7S6A with SiS745 North- and Southbridge. pciconf -lv tells me that my IDE Controller is the following: [EMAIL PROTECTED]:2:5: class=0x010180 card=0x0a411019 chip=0x55131039 rev=0xd0 hdr=0x00 vendor = 'Silicon Integrated Systems (SiS)' device = 'SiS5513 EIDE Controller (A,B step)' class= mass storage subclass = ATA The interesting dmesg lines are: jmmr# dmesg | egrep '(ad0|ata|ATA)' pci0: mass storage, ATA at device 2.5 (no driver attached) ata0 at port 0x3f6,0x1f0-0x1f7 irq 14 on isa0 ata1 at port 0x376,0x170-0x177 irq 15 on isa0 ad0: 38166MB ST340823A [77545/16/63] at ata0-master PIO4 acd0: CDROM ASUS CD-S500/A at ata1-master PIO4 ad0 ran via UDMA100 on 4.8-PRERELEASE and 5.0-RELEASE. acd0 running via PIO is ok, since hw.ata.atapi_dma is set to 0. Regards, Julian Stecklina To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Clock running double time
On Fri, Mar 14, 2003 at 11:14:51PM -0800, [EMAIL PROTECTED] wrote: Has anyone ever seen this? My clock is running double time, that is, each second it advances two seconds. Needless to say, ntpd can't sync up with any servers. You almost certainly have a motherboard with bad ACPI (probably for with a K6 processor). Try adding: kern.timecounter.hardware: TSC to /etc/sysctl.conf and rebooting. This has been reported several times now, I wonder if we should add it to the FAQ? David. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: SiS5591(?) ATA
It seems [EMAIL PROTECTED] wrote: jmmr# dmesg | egrep '(ad0|ata|ATA)' pci0: mass storage, ATA at device 2.5 (no driver attached) ata0 at port 0x3f6,0x1f0-0x1f7 irq 14 on isa0 ata1 at port 0x376,0x170-0x177 irq 15 on isa0 ad0: 38166MB ST340823A [77545/16/63] at ata0-master PIO4 acd0: CDROM ASUS CD-S500/A at ata1-master PIO4 Please make sure that ata-chipset.c is rev 1.14 which corrected a bug in the chip ident function... -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Clock running double time
On Sat, Mar 15, 2003 at 03:51:09PM +, David Malone wrote: On Fri, Mar 14, 2003 at 11:14:51PM -0800, [EMAIL PROTECTED] wrote: Has anyone ever seen this? My clock is running double time, that is, each second it advances two seconds. Needless to say, ntpd can't sync up with any servers. You almost certainly have a motherboard with bad ACPI (probably for with a K6 processor). Try adding: kern.timecounter.hardware: TSC The correct line to add to /etc/sysctl.conf is: kern.timecounter.hardware=TSC to /etc/sysctl.conf and rebooting. This has been reported several times now, I wonder if we should add it to the FAQ? David. -- Craig Rodrigues http://home.attbi.com/~rodrigc [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: SiS5591(?) ATA
On 15-Mar-2003 Soeren Schmidt wrote: Please make sure that ata-chipset.c is rev 1.14 which corrected a bug in the chip ident function... ata-chipset.c 1.14 was checked in on March 12 my kernel is from two days after. So I guess it is included. I cvsuped the same sources I used to compile my current system and it is 1.14. Could it be that this change broke UDMA support on SiS controllers? Since I can remember that it ran at UDMA66 (why not 100, I do not know) on CURRENT from 5 days or so before. Regards, Julian Stecklina To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: SiS5591(?) ATA
It seems [EMAIL PROTECTED] wrote:
On 15-Mar-2003 Soeren Schmidt wrote:
Please make sure that ata-chipset.c is rev 1.14 which corrected a
bug in the chip ident function...
ata-chipset.c 1.14 was checked in on March 12 my kernel is from two days after.
So I guess it is included. I cvsuped the same sources I used to compile my
current system and it is 1.14.
Hmm, OK, try this patch:
Index: ata-chipset.c
===
RCS file: /home/ncvs/src/sys/dev/ata/ata-chipset.c,v
retrieving revision 1.14
diff -u -r1.14 ata-chipset.c
--- ata-chipset.c 12 Mar 2003 15:45:52 - 1.14
+++ ata-chipset.c 15 Mar 2003 19:02:13 -
@@ -95,8 +95,8 @@
static void ata_sis_setmode(struct ata_device *, int);
static int ata_mode2idx(int);
static int ata_check_80pin(struct ata_device *, int);
-static int ata_find_dev(device_t, u_int32_t, u_int32_t);
-static struct ata_chip_id *ata_match_chip(device_t, struct ata_chip_id *);
+static int ata_find_dev(device_t, u_int32_t, u_int32_t, int);
+static struct ata_chip_id *ata_match_chip(device_t, struct ata_chip_id *, int);
static int ata_default_interrupt(device_t);
static void ata_pci_serialize(struct ata_channel *, int);
@@ -171,7 +171,7 @@
{ 0, 0, 0, 0, 0, 0}};
char buffer[64];
-if (!(idx = ata_match_chip(dev, ids)))
+if (!(idx = ata_match_chip(dev, ids, pci_get_slot(dev
return ENXIO;
sprintf(buffer, %s %s controller, idx-text, ata_mode2str(idx-max_dma));
@@ -321,7 +321,7 @@
{ 0, 0, 0, 0, 0, 0}};
char buffer[64];
-if (!(idx = ata_match_chip(dev, ids)))
+if (!(idx = ata_match_chip(dev, ids, pci_get_slot(dev
return ENXIO;
sprintf(buffer, %s %s controller, idx-text, ata_mode2str(idx-max_dma));
@@ -428,7 +428,7 @@
{ 0, 0, 0, 0, 0, 0}};
char buffer[64];
-if (!(idx = ata_match_chip(dev, ids)))
+if (!(idx = ata_match_chip(dev, ids, pci_get_slot(dev
return ENXIO;
sprintf(buffer, %s %s controller, idx-text, ata_mode2str(idx-max_dma));
@@ -601,7 +601,7 @@
{ 0, 0, 0, 0, 0, 0}};
char buffer[64];
-if (!(idx = ata_match_chip(dev, ids)))
+if (!(idx = ata_match_chip(dev, ids, pci_get_slot(dev
return ENXIO;
sprintf(buffer, %s %s controller, idx-text, ata_mode2str(idx-max_dma));
@@ -768,7 +768,7 @@
{ 0, 0, 0, 0, 0, 0}};
char buffer[64];
-if (!(idx = ata_match_chip(dev, ids)))
+if (!(idx = ata_match_chip(dev, ids, pci_get_slot(dev
return ENXIO;
sprintf(buffer, %s %s controller, idx-text, ata_mode2str(idx-max_dma));
@@ -887,7 +887,7 @@
{ 0, 0, 0, 0, 0, 0}};
char buffer[64];
-if (!(idx = ata_match_chip(dev, ids)))
+if (!(idx = ata_match_chip(dev, ids, pci_get_slot(dev
return ENXIO;
sprintf(buffer, %s %s controller, idx-text, ata_mode2str(idx-max_dma));
@@ -944,7 +944,7 @@
char *desc, buffer[64];
uintptr_t devid = 0;
-if (!(idx = ata_match_chip(dev, ids)))
+if (!(idx = ata_match_chip(dev, ids, pci_get_slot(dev
return ENXIO;
/* if we are on a SuperTrak SX6000 dont attach */
@@ -1188,7 +1188,7 @@
{ 0, 0, 0, 0, 0, 0}};
char buffer[64];
-if (!(idx = ata_match_chip(dev, ids)))
+if (!(idx = ata_match_chip(dev, ids, pci_get_slot(dev
return ENXIO;
sprintf(buffer, %s %s controller, idx-text, ata_mode2str(idx-max_dma));
@@ -1276,7 +1276,7 @@
{ 0, 0, 0, 0, 0, 0}};
char buffer[64];
-if (!(idx = ata_match_chip(dev, ids)))
+if (!(idx = ata_match_chip(dev, ids, pci_get_slot(dev
return ENXIO;
sprintf(buffer, %s %s controller, idx-text, ata_mode2str(idx-max_dma));
@@ -1501,7 +1501,7 @@
{ 0, 0, 0, 0, 0, 0 }};
char buffer[64];
-if (!(idx = ata_match_chip(dev, ids)))
+if (!(idx = ata_match_chip(dev, ids, -1)))
return ENXIO;
if (idx-cfg1 == SIS_SOUTH) {
@@ -1511,7 +1511,7 @@
sprintf(buffer, SiS 96X %s controller,ata_mode2str(idx-max_dma));
}
else {
- if (ata_find_dev(dev, ATA_SISSOUTH, 0x10))
+ if (ata_find_dev(dev, ATA_SISSOUTH, 0x10, pci_get_slot(dev)))
idx-cfg1 = SIS133OLD;
else {
idx-max_dma = ATA_UDMA5;
@@ -1659,7 +1659,7 @@
{ 0, 0, 0, 0, 0, 0 }};
char buffer[64];
-if (!(idx = ata_match_chip(dev, ids)))
+if (!(idx = ata_match_chip(dev, ids, pci_get_slot(dev
return ENXIO;
sprintf(buffer, %s %s controller, idx-text, ata_mode2str(idx-max_dma));
@@ -1808,16 +1808,16 @@
}
static int
-ata_find_dev(device_t dev, u_int32_t devid, u_int32_t revid)
+ata_find_dev(device_t dev, u_int32_t devid, u_int32_t revid, int slot)
{
device_t *children;
-int nchildren, i, slot = pci_get_slot(dev);
+int nchildren, i;
if (device_get_children(device_get_parent(dev), children, nchildren))
Re: SiS5591(?) ATA
From: Soeren Schmidt [EMAIL PROTECTED] Subject: Re: SiS5591(?) ATA Date: Sat, 15 Mar 2003 20:06:33 +0100 (CET) Message-ID: [EMAIL PROTECTED] Hmm, OK, try this patch: become better. but still it does't work in UDMA100. atapci0: SiS 961 UDMA100 controller port 0xff00-0xff0f at device 2.5 on pci0 ata0: at 0x1f0 irq 14 on atapci0 ata1: at 0x170 irq 15 on atapci0 ad0: DMA limited to UDMA33, non-ATA66 cable or device ad0: 78533MB IC35L080AVVA07-0 [159560/16/63] at ata0-master UDMA33 ad1: DMA limited to UDMA33, non-ATA66 cable or device ad1: 39266MB IC35L040AVER07-0 [79780/16/63] at ata0-slave UDMA33 ata1-master: DMA limited to UDMA33, non-ATA66 cable or device acd0: DVD-R MATSHITADVD-RAM SW-9571 at ata1-master UDMA33 Regards, To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: SiS5591(?) ATA
It seems FUJITA Kazutoshi wrote: become better. but still it does't work in UDMA100. atapci0: SiS 961 UDMA100 controller port 0xff00-0xff0f at device 2.5 on pci0 ata0: at 0x1f0 irq 14 on atapci0 ata1: at 0x170 irq 15 on atapci0 ad0: DMA limited to UDMA33, non-ATA66 cable or device ad0: 78533MB IC35L080AVVA07-0 [159560/16/63] at ata0-master UDMA33 ad1: DMA limited to UDMA33, non-ATA66 cable or device ad1: 39266MB IC35L040AVER07-0 [79780/16/63] at ata0-slave UDMA33 ata1-master: DMA limited to UDMA33, non-ATA66 cable or device acd0: DVD-R MATSHITADVD-RAM SW-9571 at ata1-master UDMA33 Hmm, the cable detection sems to be failing somehow... Now is the chip found correctly ? is it *really* a SiS 961 (old ATA100 model)? -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: crash: lockmgr: locking against myself
From: Tim Robbins [EMAIL PROTECTED] Subject: Re: crash: lockmgr: locking against myself Date: Sun, 16 Mar 2003 00:36:41 +1100 Message-ID: [EMAIL PROTECTED] Here's a simple untested patch to try which makes udf_allocv() return an unlocked vnode. I'm not sure whether the locking in udf_hashins() is right. It looks good for me. At least, crash is avoided and mount successfully. Regards, To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: SiS5591(?) ATA
On 15-Mar-2003 Soeren Schmidt wrote: atapci0: SiS 961 UDMA100 controller port 0xff00-0xff0f at device 2.5 on pci0 ata0: at 0x1f0 irq 14 on atapci0 ata1: at 0x170 irq 15 on atapci0 ad0: DMA limited to UDMA33, non-ATA66 cable or device ad0: 78533MB IC35L080AVVA07-0 [159560/16/63] at ata0-master UDMA33 ad1: DMA limited to UDMA33, non-ATA66 cable or device ad1: 39266MB IC35L040AVER07-0 [79780/16/63] at ata0-slave UDMA33 ata1-master: DMA limited to UDMA33, non-ATA66 cable or device acd0: DVD-R MATSHITADVD-RAM SW-9571 at ata1-master UDMA33 Hmm, the cable detection sems to be failing somehow... Yes. atapci0: SiS 745 UDMA100 controller port 0x4000-0x400f at device 2.5 on pci0 No problem here: I *really* have a SiS 745 controller. :) ata0: at 0x1f0 irq 14 on atapci0 ata1: at 0x170 irq 15 on atapci0 ad0: DMA limited to UDMA33, non-ATA66 cable or device ad0: 38166MB ST340823A [77545/16/63] at ata0-master UDMA33 This should be UDMA100. ata1-master: DMA limited to UDMA33, non-ATA66 cable or device acd0: CDROM ASUS CD-S500/A at ata1-master UDMA33 No problem here, too. My CDROM does only support UDMA33. Regards, Julian Stecklina To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: panic on boot (devfs_find)
--- Conrad Sabatier [EMAIL PROTECTED] wrote: Booting in verbose mode, I see the last thing that occurs just before the panic is mounting root and then starting (or trying to start) /sbin/init. After an initial hang, it drops into ddb. -- I found the same problem for the last two days. However, it seems that this problem doesn't appear in the GENERIC kernel. I have tried putting the INVARIANTS stuffs back to my custom config file and it works as well. Very strange... I may have some spare time to search for the break point later and will post if I can find any commit that causes this. Regards, __ Do you Yahoo!? Yahoo! Web Hosting - establish your business online http://webhosting.yahoo.com To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: SiS5591(?) ATA
From: Soeren Schmidt [EMAIL PROTECTED] Subject: Re: SiS5591(?) ATA Date: Sat, 15 Mar 2003 21:14:16 +0100 (CET) Message-ID: [EMAIL PROTECTED] Hmm, the cable detection sems to be failing somehow... Now is the chip found correctly ? is it *really* a SiS 961 (old ATA100 model)? How can I make it sure? According to the M/B manual, it looks having SiS961. My M/B is MS9317E which chipset is SiS650. (http://www.matsonic.com.tw/eng/productsdata/ms9317e.htm) Regards, To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
UDF: bad file descriptor
From: FUJITA Kazutoshi [EMAIL PROTECTED] Subject: Re: crash: lockmgr: locking against myself Date: Sun, 16 Mar 2003 05:23:51 +0900 (JST) Message-ID: [EMAIL PROTECTED] It looks good for me. At least, crash is avoided and mount successfully. I could mount DVD-RAM successfully. (This media was formatted by TOSHIBA HDDDVD video recorder;-p) But, some files can't be read. How can I solve this? # /bin/ls . .. VR_MANGR.BUPVR_MANGR.IFOVR_MOVIE.VRO # /bin/ls -l ls: VR_MOVIE.VRO: Bad file descriptor total 111 drw-rw-rw- 1 root wheel 2048 Mar 12 13:33 . drw-rw-rw- 4 root wheel 2048 Mar 16 18:00 .. -rw-rw-rw- 1 root wheel 56980 Mar 16 18:01 VR_MANGR.BUP -rw-rw-rw- 1 root wheel 56980 Mar 16 18:01 VR_MANGR.IFO Regards, To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
if_iso88025subr.c: doesn't compile.
So far today this file has been updated four times and it still won't compile. Can this be debugged off-line before being committed? I'm trying to debug another problem and I haven't been able to work on it all day because of this problem. Thanks. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: kern/49079: panic: bwrite: buffer is not busy
On Fri, Mar 14, 2003 at 06:47:27PM +0100, Morten Rodal wrote:
[snip the parent post]
I just got another one of these. This time it didn't double panic
while syncing the disks. I've been getting this quite often now,
almost daily. If there is anything else I can help you with to get to
the bottom of this problem don't hesitate to ask.
Attached is a the gdb output and the backtrace from DDB.
--
Morten Rodal
panic: bwrite: buffer is not busy???
cpuid = 1; lapic.id =
Stack backtrace:
backtrace(c0341972,0,c03448b1,d533f988,1) at backtrace+0x17
panic(c03448b1,d533f99c,c0304cd9,d533f99c,c01da2c4) at panic+0x10a
bwrite(cc9a5fe8,d533fa34,c02220e2,cc9a5fe8,cc9a6118) at bwrite+0x152
bawrite(cc9a5fe8,cc9a6118,4,d533fd48,2002) at bawrite+0x1c
cluster_wbuild(c41b1a44,4000,e,0,6) at cluster_wbuild+0x732
cluster_write(cc9afa98,58000,0,2,c3fdc300) at cluster_write+0x571
ffs_write(d533fbc4,20002,c38d5c30,0,d533fc70) at ffs_write+0x5cf
vn_write(c3ec26cc,d533fc70,c3fdc300,0,c38d5c30) at vn_write+0x20d
dofilewrite(c38d5c30,c3ec26cc,1d,859e800,200) at dofilewrite+0xe8
write(c38d5c30,d533fd10,c,d533fd20,3) at write+0x69
syscall(8e4002f,2f,bfbf002f,0,2808f100) at syscall+0x2ac
Xint0x80_syscall() at Xint0x80_syscall+0x1d
--- syscall (4), eip = 0x285ba6d3, esp = 0xbfbff21c, ebp = 0xbfbff258 ---
Script started on Sat Mar 15 23:02:18 2003
slurp# gdb -k kernel.3 vmcore.3
GNU gdb 5.2.1 (FreeBSD)
Copyright 2002 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type show copying to see the conditions.
There is absolutely no warranty for GDB. Type show warranty for details.
This GDB was configured as i386-undermydesk-freebsd...
panic: bwrite: buffer is not busy???
panic messages:
---
panic: bwrite: buffer is not busy???
cpuid = 1; lapic.id =
Stack backtrace:
boot() called on cpu#1
syncing disks, buffers remaining... 3452 3452 3451 3451 3449 3448 3448 3448 3448 3448
3448 3448 3448 3448 3448 3448 3448 3448 3448 3448 3448 3448 3448 3448 3448
giving up on 110 buffers
Uptime: 48m16s
Dumping 447 MB
[CTRL-C to abort] [CTRL-C to abort] [CTRL-C to abort] [CTRL-C to abort] [CTRL-C to
abort] [CTRL-C to abort] [CTRL-C to abort] [CTRL-C to abort] [CTRL-C to abort] [CTRL-C
to abort] [CTRL-C to abort] [CTRL-C to abort] [CTRL-C to abort] [CTRL-C to abort]
[CTRL-C to abort] [CTRL-C to abort] [CTRL-C to abort] [CTRL-C to abort] [CTRL-C to
abort] [CTRL-C to abort] [CTRL-C to abort] [CTRL-C to abort] [CTRL-C to abort] [CTRL-C
to abort] [CTRL-C to abort] [CTRL-C to abort] [CTRL-C to abort] [CTRL-C to abort]
[CTRL-C to abort] [CTRL-C to abort] [CTRL-C to abort] [CTRL-C to abort] [CTRL-C to
abort] [CTRL-C to abort] [CTRL-C to abort] [CTRL-C to abort] 16[CTRL-C to abort]
[CTRL-C to abort] [CTRL-C to abort] [CTRL-C to abort] 32[CTRL-C to abort] [CTRL-C to
abort] [CTRL-C to abort] [CTRL-C to abort] [CTRL-C to abort] [CTRL-C to abort] 48 64
80 96 112 128 144 160 176 192 208 224 240 256 272 288 304 320 336 352 368 384 400 416
432
---
#0 doadump () at /usr/src/sys/kern/kern_shutdown.c:239
239 dumping++;
(kgdb) bt
#0 doadump () at /usr/src/sys/kern/kern_shutdown.c:239
#1 0xc01d457f in boot (howto=256) at /usr/src/sys/kern/kern_shutdown.c:371
#2 0xc01d4907 in panic () at /usr/src/sys/kern/kern_shutdown.c:542
#3 0xc02194e2 in bwrite (bp=0xcc9a5fe8) at /usr/src/sys/kern/vfs_bio.c:802
#4 0xc0219e6c in bawrite (bp=0x0) at /usr/src/sys/kern/vfs_bio.c:1144
#5 0xc02220e2 in cluster_wbuild (vp=0xc41b1a44, size=16384, start_lbn=17,
len=6) at /usr/src/sys/kern/vfs_cluster.c:966
#6 0xc0221931 in cluster_write (bp=0xcc9afa98, filesize=360448, seqcount=2)
at /usr/src/sys/kern/vfs_cluster.c:566
#7 0xc02aa1ef in ffs_write (ap=0xd533fbc4)
at /usr/src/sys/ufs/ffs/ffs_vnops.c:726
#8 0xc023885d in vn_write (fp=0xc3ec26cc, uio=0xd533fc70,
active_cred=0xc3fdc300, flags=0, td=0xc38d5c30) at vnode_if.h:417
#9 0xc01f7fb8 in dofilewrite (td=0xc38d5c30, fp=0xc3ec26cc, fd=0,
buf=0x859e800, nbyte=0, offset=0, flags=0) at file.h:239
#10 0xc01f7df9 in write (td=0xc38d5c30, uap=0xd533fd10)
at /usr/src/sys/kern/sys_generic.c:329
#11 0xc030d09c in syscall (frame=
{tf_fs = 149159983, tf_es = 47, tf_ds = -1078001617, tf_edi = 0, tf_esi =
671674624, tf_ebp = -1077939624, tf_isp = -718013068, tf_ebx = 671686852, tf_edx = 29,
tf_ecx = 0, tf_eax = 4, tf_trapno = 0, tf_err = 2, tf_eip = 677095123, tf_cs = 31,
tf_eflags = 518, tf_esp = -1077939684, tf_ss = 47})
at /usr/src/sys/i386/i386/trap.c:1030
#12 0xc02f52cd in Xint0x80_syscall () at {standard input}:139
---Can't read userspace from dump, or kernel process---
(kgdb) slurp# ^Dexit
Script done on Sat Mar 15 23:02:30 2003
pgp0.pgp
Description: PGP signature
Re: Vinum R5
On Saturday, 15 March 2003 at 10:34:54 +0200, Vallo Kallaste wrote: On Sat, Mar 15, 2003 at 12:02:23PM +1030, Greg 'groggy' Lehey [EMAIL PROTECTED] wrote: -current, system did panic everytime at the end of initialisation of parity (raidctl -iv raid?). So I used the raidframe patch for -stable at http://people.freebsd.org/~scottl/rf/2001-08-28-RAIDframe-stable.diff.gz Had to do some patching by hand, but otherwise works well. I don't think that problems with RAIDFrame are related to these problems with Vinum. I seem to remember a commit to the head branch recently (in the last 12 months) relating to the problem you've seen. I forget exactly where it went (it wasn't from me), and in cursory searching I couldn't find it. It's possible that it hasn't been MFC'd, which would explain your problem. If you have a 5.0 machine, it would be interesting to see if you can reproduce it there. Yes, yes, the whole raidframe story was meant as information about the conditions I did the raidframe vs. Vinum testing on. Nothing to do with Vinum, besides that raidframe works and Vinum does not. Will it suffice to switch off power for one disk to simulate more real-world disk failure? Are there any hidden pitfalls for failing and restoring operation of non-hotswap disks? I don't think so. It was more thinking aloud than anything else. As I said above, this is the way I tested things in the first place. Ok, I'll try to simulate the disk failure by switching off the power, then. I think you misunderstand. I simulated the disk failures by doing a stop -f. I can't see any way that the way they go down can influence the revive integrity. I can see that powering down might not do the disks any good. Greg -- See complete headers for address and phone numbers pgp0.pgp Description: PGP signature
Re: Vinum R5
In message [EMAIL PROTECTED], Greg 'groggy' Lehey writes: Ok, I'll try to simulate the disk failure by switching off the power, then. I think you misunderstand. I simulated the disk failures by doing a stop -f. I can't see any way that the way they go down can influence the revive integrity. I can see that powering down might not do the disks any good. Are you saying that you only tested vinums recovery with disks which had been cleanly shut down ? -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Vinum R5
On Saturday, 15 March 2003 at 23:56:24 +0100, Poul-Henning Kamp wrote: In message [EMAIL PROTECTED], Greg 'groggy' Lehey writes: Ok, I'll try to simulate the disk failure by switching off the power, then. I think you misunderstand. I simulated the disk failures by doing a stop -f. I can't see any way that the way they go down can influence the revive integrity. I can see that powering down might not do the disks any good. Are you saying that you only tested vinums recovery with disks which had been cleanly shut down ? No. stop -f doesn't shut down cleanly. But I also tested with powering down. As you might expect, it didn't make much difference. Greg -- See complete headers for address and phone numbers pgp0.pgp Description: PGP signature
Re: Top weirdness.
Craig, That's the normal output of 'top -S'. Regards, Andre Guibert de Bruet | Enterprise Software Consultant Silicon Landmark, LLC. | http://siliconlandmark.com/ On Sat, 15 Mar 2003, Craig Reyenga wrote: Check these out: http://chat.carleton.ca/~creyenga/1sttime.JPG http://chat.carleton.ca/~creyenga/again.JPG Pretty strange, my normally-aspirated computer is somehow using 168% of cpu. boss# uname -a FreeBSD boss.sewer.org 5.0-CURRENT FreeBSD 5.0-CURRENT #0: Fri Mar 7 01:49:18 EST 2003 [EMAIL PROTECTED]:/usr/obj/usr/s/run/src/sys/BOSSKERN i386 Using SCHED_4BSD. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Top weirdness.
'cc1' is _not_ a system process. How is this normal? -Craig - Original Message - From: Andre Guibert de Bruet [EMAIL PROTECTED] To: Craig Reyenga [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Saturday, March 15, 2003 19:52 Subject: Re: Top weirdness. Craig, That's the normal output of 'top -S'. Regards, Andre Guibert de Bruet | Enterprise Software Consultant Silicon Landmark, LLC. | http://siliconlandmark.com/ On Sat, 15 Mar 2003, Craig Reyenga wrote: Check these out: http://chat.carleton.ca/~creyenga/1sttime.JPG http://chat.carleton.ca/~creyenga/again.JPG Pretty strange, my normally-aspirated computer is somehow using 168% of cpu. boss# uname -a FreeBSD boss.sewer.org 5.0-CURRENT FreeBSD 5.0-CURRENT #0: Fri Mar 7 01:49:18 EST 2003 [EMAIL PROTECTED]:/usr/obj/usr/s/run/src/sys/BOSSKERN i386 Using SCHED_4BSD. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: if_iso88025subr.c: doesn't compile.
On Sat, 15 Mar 2003, walt wrote: So far today this file has been updated four times and it still won't compile. Can this be debugged off-line before being committed? You just happened to catch it at a bad time. Sorry for the trouble. -- | Matthew N. Dodd | '78 Datsun 280Z | '75 Volvo 164E | FreeBSD/NetBSD | | [EMAIL PROTECTED] | 2 x '84 Volvo 245DL| ix86,sparc,pmax | | http://www.jurai.net/~winter | For Great Justice! | ISO8802.5 4ever | To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Top weirdness.
Craig, It's not a system process, but it's GCC (step 2) running as root. You were building software (ports, kernel or other) when the screenshot was taken. top -S displays non-system processes as well as system processes. The 168% in the weighed CPU field is a little odd, but it's an approximated average and as such, is not always perfectly accurate. Regards, Andre Guibert de Bruet | Enterprise Software Consultant Silicon Landmark, LLC. | http://siliconlandmark.com/ On Sat, 15 Feb 2003, Craig Reyenga wrote: 'cc1' is _not_ a system process. How is this normal? -Craig - Original Message - From: Andre Guibert de Bruet [EMAIL PROTECTED] To: Craig Reyenga [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Saturday, March 15, 2003 19:52 Subject: Re: Top weirdness. Craig, That's the normal output of 'top -S'. Regards, Andre Guibert de Bruet | Enterprise Software Consultant Silicon Landmark, LLC. | http://siliconlandmark.com/ On Sat, 15 Mar 2003, Craig Reyenga wrote: Check these out: http://chat.carleton.ca/~creyenga/1sttime.JPG http://chat.carleton.ca/~creyenga/again.JPG Pretty strange, my normally-aspirated computer is somehow using 168% of cpu. boss# uname -a FreeBSD boss.sewer.org 5.0-CURRENT FreeBSD 5.0-CURRENT #0: Fri Mar 7 01:49:18 EST 2003 [EMAIL PROTECTED]:/usr/obj/usr/s/run/src/sys/BOSSKERN i386 Using SCHED_4BSD. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: UDF: bad file descriptor
On Sun, 16 Mar 2003, FUJITA Kazutoshi wrote: I could mount DVD-RAM successfully. But, some files can't be read. How can I solve this? # /bin/ls . .. VR_MANGR.BUPVR_MANGR.IFOVR_MOVIE.VRO # /bin/ls -l ls: VR_MOVIE.VRO: Bad file descriptor total 111 drw-rw-rw- 1 root wheel 2048 Mar 12 13:33 . drw-rw-rw- 4 root wheel 2048 Mar 16 18:00 .. -rw-rw-rw- 1 root wheel 56980 Mar 16 18:01 VR_MANGR.BUP -rw-rw-rw- 1 root wheel 56980 Mar 16 18:01 VR_MANGR.IFO Sounds like the lstat on VR_MOVIE.VRO is failing. Does 'truss ls -l' display anything relevant? Andre Guibert de Bruet | Enterprise Software Consultant Silicon Landmark, LLC. | http://siliconlandmark.com/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: bluetooth BW-BH02U reset failure
Hello Maksim, At first, I installed 5-CURRENT on P3 machine and sync with cvsup to latest. and overwrite 2003-03-05 maksim's bluetooth modules. please verify that tarball you have downloaded has both kernel and userland stuff, i.e. you have sys, share, usr.bin and usr.sbin in the snapshot's src/ directory. if not please download updated snapshot from the same location. OK, I checked my copy of 2003-03-05. It only has sys. I'd download latest 2003-03-05 on your directory. I've rebuild environment. I tried to use planex(http://www.planex.co.jp/) BW-BH02U BlueTooth USB dongle. I plugged BW-BH02U in to FreeBSD without any ko module. FreeBSD found that device with ugen0. following message got with usbdevs -v and udesc_dump. ugen(4) is generic USB device driver. you need to load ng_ubt(4) driver before plugging your device. ugen0: Broadcom product 0x2033, rev 1.01/0.a0, addr 2 I just mistake device name, it not BW-BH02U. true name is GW-BH02U. D-Link DBW-120M, but there is D-Link DWB-120M. it could be that i mistyped the name. is that the one you have http://www.dlink.com/products/usb/dwb120m/ the bad news is that page says its Mac only. also it seems in order to make D-Link DWB-120M work on PC you need to download some sort of firmware into it. according to D-Link there is another adapter D-Link DBT-120 http://www.dlink.com/products/usb/dbt120/ and the page says it works with Mac PC. also to make things very confusing according to BlueZ page there are two revisions of DBT-120. One has Broadcomm chip (Rev A1) and other CSR chip (Rev B1). The version with Broadcomm chip (Rev A1) also needs firmware download. Version with CSR chip (Rev B1) works just as it is. I check that site, but I cannot find any topic and drivers out. also WWW.planex.co.jp does not have any new information. i will have to go back to the original tester for clarification on that. sorry i do not have this device my self. No problem. if you have original D-Link DWB-120M or D-Link DBT-120 (Rev A1) than for now you out of luck :( i need to get one of these devices myself to figure out how to download firmware and add proper support in ng_ubt(4) driver. i have downloaded w2k driver for D-Link DBT-120 and will try to poke around later. I tried to get DBT-120M, but I cannot get yet. fortunately, I got another device. It is HASEGAWA SYS-COM's HNT-UB01. I checked this device with usbdevs. ng_ubt asked this device is MITSUMI(0x3ee) BT_DONGLE(0x641f) This device is work on my environment(some time failure in reset, initialize I cannot solved yet why that failure). following message is this devices' one. Action is connect - start - stop - disconnect -# hcidump HCIDump - HCI packet analyzer ver 1.4 device: any snap_len: 65535 filter: 0x HCI Command: Reset(0x03|0x0003) plen 0 HCI Event: Command Complete(0x0e) plen 4 HCI Event: Command Status(0x0f) plen 4 HCI Command: Read BD ADDR(0x04|0x0009) plen 0 HCI Event: Command Complete(0x0e) plen 10 HCI Command: Read Local Supported Features(0x04|0x0003) plen 0 HCI Event: Command Complete(0x0e) plen 12 HCI Command: Read Buffer Size(0x04|0x0005) plen 0 HCI Event: Command Complete(0x0e) plen 11 HCI Command: Write Scan Enable(0x03|0x001a) plen 1 HCI Event: Command Complete(0x0e) plen 4 HCI Command: Write Class of Device(0x03|0x0024) plen 3 HCI Event: Command Complete(0x0e) plen 4 HCI Command: Change Local Name(0x03|0x0013) plen 248 HCI Event: Command Complete(0x0e) plen 4 -- dmesg ubt0: Mitsumi product 0x641f, rev 1.10/1.14, addr 2 ubt0: Interface 0 endpoints: interrupt=0x81, bulk-in=0x82, bulk-out=0x2 ubt0: Interface 1 (alt.config 5) endpoints: isoc-in=0x83, isoc-out=0x3; wMaxPacketSize=49; nframes=6, buffer size=294 ng_hci_process_event: ubt0hci - got HCI event=0xe, length=4 ng_hci_process_event: ubt0hci - got HCI event=0xf, length=4 ng_hci_process_event: ubt0hci - got HCI event=0xe, length=10 ng_hci_process_event: ubt0hci - got HCI event=0xe, length=12 ng_hci_process_event: ubt0hci - got HCI event=0xe, length=11 ng_hci_process_event: ubt0hci - got HCI event=0xe, length=4 ng_hci_process_event: ubt0hci - got HCI event=0xe, length=4 ng_hci_process_event: ubt0hci - got HCI event=0xe, length=4 ng_l2cap_lower_rcvmsg: ubt0l2cap - HCI node is up, bdaddr: xx:xx:xx:xx:xx:xx, pkt_size=128 bytes, num_pkts=8 ng_btsocket_l2cap_default_msg_input: Updating hook ubt0l2c, src bdaddr=xx:xx:xx:xx:xx:xx ng_btsocket_l2cap_raw_input: Updating hook ubt0ctl, src bdaddr=xx:xx:xx:xx:xx:xx ubt_bulk_in_complete: ubt0 - Bulk-in xfer failed. IOERROR (13) ubt_bulk_in_complete: ubt0 - Bulk-in xfer failed. IOERROR (13) ubt_intr_complete: ubt0 - Interrupt xfer failed. IOERROR (13) 12 time repeats last 3 lines ubt_bulk_in_complete: ubt0 - Bulk-in xfer failed. IOERROR (13) ubt0: at uhub0 port 2 (addr 2) disconnected ubt_bulk_in_complete: ubt0 - Bulk-in xfer failed. IOERROR (13) - 19 times repeat last line
Re: panic on boot (devfs_find)
On 15-Mar-2003 Shizuka Kudo wrote: --- Conrad Sabatier [EMAIL PROTECTED] wrote: Booting in verbose mode, I see the last thing that occurs just before the panic is mounting root and then starting (or trying to start) /sbin/init. After an initial hang, it drops into ddb. -- I found the same problem for the last two days. However, it seems that this problem doesn't appear in the GENERIC kernel. I have tried putting the INVARIANTS stuffs back to my custom config file and it works as well. Very strange... Yes, it is very strange. Yesterday, all of the kernels I compiled were bombing in devfs_find(). Today, the kernels I've tried are now bombing in devfs_vmkdir(). I compiled today using minimal CFLAGS, just -O -pipe, no -march stuff. I may have some spare time to search for the break point later and will post if I can find any commit that causes this. -- Conrad Sabatier [EMAIL PROTECTED] - In Unix veritas To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: UDF: bad file descriptor
From: Andre Guibert de Bruet [EMAIL PROTECTED] Subject: Re: UDF: bad file descriptor Date: Sat, 15 Mar 2003 21:09:55 -0500 (EST) Message-ID: [EMAIL PROTECTED] # /bin/ls -l ls: VR_MOVIE.VRO: Bad file descriptor total 111 drw-rw-rw- 1 root wheel 2048 Mar 12 13:33 . drw-rw-rw- 4 root wheel 2048 Mar 16 18:00 .. -rw-rw-rw- 1 root wheel 56980 Mar 16 18:01 VR_MANGR.BUP -rw-rw-rw- 1 root wheel 56980 Mar 16 18:01 VR_MANGR.IFO Sounds like the lstat on VR_MOVIE.VRO is failing. Does 'truss ls -l' display anything relevant? It seems there is no relevant. # truss /bin/ls -l ioctl(1,TIOCGETA,0xbfbff3b0) = 0 (0x0) ioctl(1,TIOCGWINSZ,0xbfbff414) = 0 (0x0) getuid() = 0 (0x0) readlink(/etc/malloc.conf,0xbfbff300,63) ERR#2 'No such file or directory' issetugid() = 0 (0x0) getuid() = 0 (0x0) mmap(0x0,4096,0x3,0x1002,-1,0x0) = 671887360 (0x280c3000) break(0x80d5000) = 0 (0x0) break(0x80d6000) = 0 (0x0) break(0x80d7000) = 0 (0x0) break(0x80d8000) = 0 (0x0) lstat(.,0x80d7148) = 0 (0x0) open(.,0x0,00) = 3 (0x3) fchdir(0x3) = 0 (0x0) open(.,0x0,00) = 4 (0x4) stat(.,0xbfbff2c0) = 0 (0x0) open(.,0x4,00) = 5 (0x5) fstat(5,0xbfbff2c0) = 0 (0x0) fcntl(0x5,0x2,0x1) = 0 (0x0) __sysctl(0xbfbff170,0x2,0x80cf4dc,0xbfbff16c,0x0,0x0) = 0 (0x0) fstatfs(0x5,0xbfbff1c0) = 0 (0x0) break(0x80d9000) = 0 (0x0) fstat(5,0xbfbff2c0) = 0 (0x0) fchdir(0x5) = 0 (0x0) getdirentries(0x5,0x80d8000,0x1000,0x80d5054)= 96 (0x60) lstat(.,0x80d7248) = 0 (0x0) lstat(..,0x80d7348)= 0 (0x0) lstat(VR_MOVIE.VRO,0x80d7448) ERR#9 'Bad file descriptor' lstat(VR_MANGR.BUP,0x80d7548) = 0 (0x0) lstat(VR_MANGR.IFO,0x80d7648) = 0 (0x0) getdirentries(0x5,0x80d8000,0x1000,0x80d5054)= 0 (0x0) lseek(5,0x0,0) = 0 (0x0) close(5) = 0 (0x0) fchdir(0x3) = 0 (0x0) fchdir(0x4) = 0 (0x0) close(4) = 0 (0x0) stat(/etc/nsswitch.conf,0xbfbfed60)= 0 (0x0) open(/etc/nsswitch.conf,0x0,0666) = 4 (0x4) break(0x80da000) = 0 (0x0) ioctl(4,TIOCGETA,0xbfbfec60) ERR#25 'Inappropriate ioctl for device' fstat(4,0xbfbfebb0) = 0 (0x0) break(0x80de000) = 0 (0x0) read(0x4,0x80da000,0x4000) = 0 (0x0) ioctl(4,TIOCGETA,0xbfbfec40) ERR#25 'Inappropriate ioctl for device' close(4) = 0 (0x0) geteuid()= 0 (0x0) stat(/etc/spwd.db,0xbfbfeca0) = 0 (0x0) open(/etc/spwd.db,0x0,00) = 4 (0x4) fcntl(0x4,0x2,0x1) = 0 (0x0) read(0x4,0x80d8200,0x104)= 260 (0x104) lseek(4,0x5000,0)= 20480 (0x5000) read(0x4,0x80da000,0x1000) = 4096 (0x1000) lseek(4,0x4000,0)= 16384 (0x4000) read(0x4,0x80db000,0x1000) = 4096 (0x1000) open(/etc/group,0x0,0666) = 5 (0x5) fstat(5,0xbfbfec80) = 0 (0x0) break(0x80e2000) = 0 (0x0) lseek(5,0x0,1) = 0 (0x0) lseek(5,0x0,0) = 0 (0x0) stat(/etc/nsswitch.conf,0xbfbfed40)= 0 (0x0) read(0x5,0x80de000,0x4000) = 378 (0x17a) ls: write(2,0xbfbfe4d0,4)= 4 (0x4) VR_MOVIE.VRO: Bad file descriptorwrite(2,0xbfbfe4f0,33) = 33 (0x21) write(2,0x80c4733,1) = 1 (0x1) fstat(1,0xbfbfe850) = 0 (0x0) ioctl(1,TIOCGETA,0xbfbfe890) = 0 (0x0) total 111 write(1,0x80dc000,10)= 10 (0xa) pathconf(0xbfbfe9d0,0x3b)ERR#22 'Invalid argument' gettimeofday(0xbfbfed78,0x0) = 0 (0x0) access(/etc/localtime,4) = 0 (0x0) open(/etc/localtime,0x0,00)= 6 (0x6)
Re: GEOM_MBR breaks my kernel
Poul-Henning Kamp wrote: In message [EMAIL PROTECTED], walt writes: I've been unable to boot any kernel I've built since about March 11 and I've narrowed it down to the GEOM_MBR option. With GEOM_MBR I get a kernel page fault error when trying to mount the root filesystem at boot time. Can you get us the messages and a traceback ? Well, no. I've been trying to find a kernel configuration that will allow me to reproduce the bug AND generate a traceback, but so far I can't find one. The problem is that just adding GEOM_MBR to a GENERIC kernel doesn't produce the bug. My normal custom kernel doesn't contain the debugging stuff, and if I start changing things the bug doesn't show. The only semi-interesting result I've come up with is this: I normally use only the 'cpu I686_CPU' flag because I have an Athlon cpu. But if I also include the 'cpu I586_CPU' flag the bug completely changes: the machine boots and the filesystems mount just fine but about ten seconds after I start X running the machine panics and reboots shortly thereafter. The panic message doesn't appear on the screen because the console is not visible at that point. Does this suggest a gcc problem? I've never really understood how more than one 'cpu' flag can be included in the kernel config file, so I'm not sure what actually changes when I do that. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: UDF: bad file descriptor
Hi, Sorry for neglecting UDF for so long. Regarding this problem, what program was used to generate the UDF filesystem on the disk? If the disk doesn't have much data on it, would it be possible to 'dd' an image of the disk to a file and send me the file? Scott FUJITA Kazutoshi wrote: From: Andre Guibert de Bruet [EMAIL PROTECTED] Subject: Re: UDF: bad file descriptor Date: Sat, 15 Mar 2003 21:09:55 -0500 (EST) Message-ID: [EMAIL PROTECTED] # /bin/ls -l ls: VR_MOVIE.VRO: Bad file descriptor total 111 drw-rw-rw- 1 root wheel 2048 Mar 12 13:33 . drw-rw-rw- 4 root wheel 2048 Mar 16 18:00 .. -rw-rw-rw- 1 root wheel 56980 Mar 16 18:01 VR_MANGR.BUP -rw-rw-rw- 1 root wheel 56980 Mar 16 18:01 VR_MANGR.IFO Sounds like the lstat on VR_MOVIE.VRO is failing. Does 'truss ls -l' display anything relevant? It seems there is no relevant. # truss /bin/ls -l ioctl(1,TIOCGETA,0xbfbff3b0) = 0 (0x0) ioctl(1,TIOCGWINSZ,0xbfbff414) = 0 (0x0) getuid() = 0 (0x0) readlink(/etc/malloc.conf,0xbfbff300,63) ERR#2 'No such file or directory' issetugid() = 0 (0x0) getuid() = 0 (0x0) mmap(0x0,4096,0x3,0x1002,-1,0x0) = 671887360 (0x280c3000) break(0x80d5000) = 0 (0x0) break(0x80d6000) = 0 (0x0) break(0x80d7000) = 0 (0x0) break(0x80d8000) = 0 (0x0) lstat(.,0x80d7148) = 0 (0x0) open(.,0x0,00) = 3 (0x3) fchdir(0x3) = 0 (0x0) open(.,0x0,00) = 4 (0x4) stat(.,0xbfbff2c0) = 0 (0x0) open(.,0x4,00) = 5 (0x5) fstat(5,0xbfbff2c0) = 0 (0x0) fcntl(0x5,0x2,0x1) = 0 (0x0) __sysctl(0xbfbff170,0x2,0x80cf4dc,0xbfbff16c,0x0,0x0) = 0 (0x0) fstatfs(0x5,0xbfbff1c0) = 0 (0x0) break(0x80d9000) = 0 (0x0) fstat(5,0xbfbff2c0) = 0 (0x0) fchdir(0x5) = 0 (0x0) getdirentries(0x5,0x80d8000,0x1000,0x80d5054)= 96 (0x60) lstat(.,0x80d7248) = 0 (0x0) lstat(..,0x80d7348)= 0 (0x0) lstat(VR_MOVIE.VRO,0x80d7448) ERR#9 'Bad file descriptor' lstat(VR_MANGR.BUP,0x80d7548) = 0 (0x0) lstat(VR_MANGR.IFO,0x80d7648) = 0 (0x0) getdirentries(0x5,0x80d8000,0x1000,0x80d5054)= 0 (0x0) lseek(5,0x0,0) = 0 (0x0) close(5) = 0 (0x0) fchdir(0x3) = 0 (0x0) fchdir(0x4) = 0 (0x0) close(4) = 0 (0x0) stat(/etc/nsswitch.conf,0xbfbfed60)= 0 (0x0) open(/etc/nsswitch.conf,0x0,0666) = 4 (0x4) break(0x80da000) = 0 (0x0) ioctl(4,TIOCGETA,0xbfbfec60) ERR#25 'Inappropriate ioctl for device' fstat(4,0xbfbfebb0) = 0 (0x0) break(0x80de000) = 0 (0x0) read(0x4,0x80da000,0x4000) = 0 (0x0) ioctl(4,TIOCGETA,0xbfbfec40) ERR#25 'Inappropriate ioctl for device' close(4) = 0 (0x0) geteuid()= 0 (0x0) stat(/etc/spwd.db,0xbfbfeca0) = 0 (0x0) open(/etc/spwd.db,0x0,00) = 4 (0x4) fcntl(0x4,0x2,0x1) = 0 (0x0) read(0x4,0x80d8200,0x104)= 260 (0x104) lseek(4,0x5000,0)= 20480 (0x5000) read(0x4,0x80da000,0x1000) = 4096 (0x1000) lseek(4,0x4000,0)= 16384 (0x4000) read(0x4,0x80db000,0x1000) = 4096 (0x1000) open(/etc/group,0x0,0666) = 5 (0x5) fstat(5,0xbfbfec80) = 0 (0x0) break(0x80e2000) = 0 (0x0) lseek(5,0x0,1) = 0 (0x0) lseek(5,0x0,0) = 0 (0x0) stat(/etc/nsswitch.conf,0xbfbfed40)= 0 (0x0) read(0x5,0x80de000,0x4000) = 378 (0x17a) ls: write(2,0xbfbfe4d0,4)= 4 (0x4) VR_MOVIE.VRO: Bad file descriptorwrite(2,0xbfbfe4f0,33) = 33 (0x21) write(2,0x80c4733,1) = 1 (0x1) fstat(1,0xbfbfe850) = 0 (0x0) ioctl(1,TIOCGETA,0xbfbfe890) = 0 (0x0) total 111 write(1,0x80dc000,10)=
Re: panic on boot (devfs_find)
On 15-Mar-2003 Shizuka Kudo wrote: I found the same problem for the last two days. However, it seems that this problem doesn't appear in the GENERIC kernel. I have tried putting the INVARIANTS stuffs back to my custom config file and it works as well. Very strange... I just built a GENERIC kernel and it booted OK. Weird. I may have some spare time to search for the break point later and will post if I can find any commit that causes this. Thanks! -- Conrad Sabatier [EMAIL PROTECTED] - In Unix veritas To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: param.h
Are you trying to compile the -stable version of gcc? We make significant modifications to integrate it within our environment. I would not at all be suprised if the -stable version of gcc doesn't build on -current. ... You are aware that there are gcc ports set up to configure the FSF trees specifically for use on FreeBSD, right? And that includes gcc-2.95.4. ... On Fri, Mar 14, 2003 at 08:57:35PM -0800, Rhett Monteg Hollander wrote: Well, I was able to build it on -CURRENT, along with binutils and other fine software from -STABLE tree. The reason was that in several cases GCC 3.2.1 proved to be significantly slower than 2.95.4 (I mean regular integer\floating-point operations, MMX\SSE\3DNow! is a whole different story). I replaced 3.2.1 with 2.95.4, and since I did so in very brute way, latter had no clue where system includes are, and ld had amnesia too You really, really want to just use the /usr/ports/lang/gcc295 port. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: UDF: bad file descriptor
On Sun, Mar 16, 2003 at 06:06:50AM +0900, FUJITA Kazutoshi wrote:
I could mount DVD-RAM successfully.
(This media was formatted by TOSHIBA HDDDVD video recorder;-p)
But, some files can't be read.
How can I solve this?
[...]
# /bin/ls -l
ls: VR_MOVIE.VRO: Bad file descriptor
total 111
drw-rw-rw- 1 root wheel 2048 Mar 12 13:33 .
drw-rw-rw- 4 root wheel 2048 Mar 16 18:00 ..
-rw-rw-rw- 1 root wheel 56980 Mar 16 18:01 VR_MANGR.BUP
-rw-rw-rw- 1 root wheel 56980 Mar 16 18:01 VR_MANGR.IFO
The most likely explanation I can think of for this problem is that
VR_MOVIE.VRO is a real-time file:
6.11 Real-Time Files
A Real-Time file is a file that requires a minimum data-transfer rate when
writing or reading, for example, audio and video data. For these files
special read and write commands are needed. For example for CD and DVD
devices these special commands can be found in the Mount Fuji 4 specification.
A Real-Time file shall be identified by file type 249 in the File Type field
of the file's ICB Tag.
(from OSTA UDF spec, revision 2.01, March 15, 2000)
If the file is a real-time file, then the bad file descriptor errors
are occuring because FreeBSD's UDF filesystem doesn't supports this
type of file. Here's a patch that mimics the logic the Linux UDF code
uses to decide which UDF file types map to the UNIX regular file type:
Index: sys/fs/udf/udf_vfsops.c
===
RCS file: /home/ncvs/src/sys/fs/udf/udf_vfsops.c,v
retrieving revision 1.10
diff -u -r1.10 udf_vfsops.c
--- sys/fs/udf/udf_vfsops.c 11 Mar 2003 22:15:09 - 1.10
+++ sys/fs/udf/udf_vfsops.c 16 Mar 2003 03:01:28 -
@@ -618,12 +618,16 @@
switch (unode-fentry-icbtag.file_type) {
default:
+ printf(unrecognised file type %d\n,
+ (int)unode-fentry-icbtag.file_type);
vp-v_type = VBAD;
break;
case 4:
vp-v_type = VDIR;
break;
+ case 0:
case 5:
+ case 249:
vp-v_type = VREG;
break;
case 6:
The Linux driver doesn't seem to issue the special read and write commands
that the quote from the UDF spec. mentions, so I'm not sure whether
it will work. Let me know how it goes.
Tim
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: panic on boot (devfs_find)
--- Bryan Liesner [EMAIL PROTECTED] wrote: I was able to get a kernel up and running (strangely) on 3/12, but commits after that cause an immediate panic as soon as init starts. If I build a kernel from sources cut off at 3/10/2003 at 12:00, everything works fine. It is related to the sys/geom/geom_event.c commit on 3/11/2003: Revision 1.20 / (download) - annotate - [select for diffs], Mon Mar 10 23:41:41 2003 UTC (5 days, 5 hours ago) by phk Branch: MAIN CVS Tags: HEAD Changes since 1.19: +5 -0 lines Diff to previous 1.19 (colored) If we run out of consumers while orphaning them, and the provider's geom is withering, destroy the provider when done. This was exposed by the recent change to geom_dev's orphaning logic If I reverted it back to a previous version (1.19) then the machine booted OK. BTW, I also found that adding INVARIANTS options into the kernel can prevent this problem as well. Regards, __ Do you Yahoo!? Yahoo! Web Hosting - establish your business online http://webhosting.yahoo.com To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: OSS SBLive driver causes kernel panic with 5.0 current
On Fri, 7 Mar 2003, Jody Franklin wrote: I'd been keeping up with current (world/kernel) every other week or so, and until this week I had no real problems. But after the build I did on March 3rd my soundcard driver (4Front's SBLive/Audigy driver) causes a kernel panic on load. If I don't load the driver the system boots fine, and runs with no other problems. This is the message I get from the debugger when I load the driver: panic: Invalid major (-1030904368) in make_dev I've posted this info to their support forums also, their last responce was to see what they broke. Please don't cross-post -current and -questions. Major numbers are now being allocated dynamically. Sounds like the emu10k1 driver doesn't like this. My guess is, it's probably in the process of being converted over... Regards, Andre Guibert de Bruet | Enterprise Software Consultant Silicon Landmark, LLC. | http://siliconlandmark.com/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: panic on boot (devfs_find)
On Sat, 15 Mar 2003, Shizuka Kudo wrote: --- Bryan Liesner [EMAIL PROTECTED] wrote: I was able to get a kernel up and running (strangely) on 3/12, but commits after that cause an immediate panic as soon as init starts. If I build a kernel from sources cut off at 3/10/2003 at 12:00, everything works fine. It is related to the sys/geom/geom_event.c commit on 3/11/2003: Revision 1.20 / (download) - annotate - [select for diffs], Mon Mar 10 23:41:41 2003 UTC (5 days, 5 hours ago) by phk Branch: MAIN CVS Tags: HEAD Changes since 1.19: +5 -0 lines Diff to previous 1.19 (colored) If we run out of consumers while orphaning them, and the provider's geom is withering, destroy the provider when done. This was exposed by the recent change to geom_dev's orphaning logic If I reverted it back to a previous version (1.19) then the machine booted OK. BTW, I also found that adding INVARIANTS options into the kernel can prevent this problem as well. Regards, I have reverted back to rev 1.19 and all seems to be running OK. I have /dev/null, /dev/stderr, /dev/apm, and /dev/mixer back. When the faulty kernel _did_ boot (after about a million retries to coax a core dump), these devices were missing at boot, or would disappear shortly after. Thanks. I think Poul-Henning will have enough information to go with now... -- == = Bryan D. Liesner LeezSoft Communications, Inc. = = A subsidiary of LeezSoft Inc. = = [EMAIL PROTECTED]Home of the Gipper= == To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: OSS SBLive driver causes kernel panic with 5.0 current
Thus spake Andre Guibert de Bruet [EMAIL PROTECTED]: On Fri, 7 Mar 2003, Jody Franklin wrote: I'd been keeping up with current (world/kernel) every other week or so, and until this week I had no real problems. But after the build I did on March 3rd my soundcard driver (4Front's SBLive/Audigy driver) causes a kernel panic on load. If I don't load the driver the system boots fine, and runs with no other problems. This is the message I get from the debugger when I load the driver: panic: Invalid major (-1030904368) in make_dev I've posted this info to their support forums also, their last responce was to see what they broke. Please don't cross-post -current and -questions. Major numbers are now being allocated dynamically. Sounds like the emu10k1 driver doesn't like this. My guess is, it's probably in the process of being converted over... His post refers to the commercial driver, which still needs to be converted. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: kern/49079: panic: bwrite: buffer is not busy
On Sat, 15 Mar 2003, Morten Rodal wrote: On Fri, Mar 14, 2003 at 06:47:27PM +0100, Morten Rodal wrote: [snip the parent post] I just got another one of these. This time it didn't double panic while syncing the disks. I've been getting this quite often now, almost daily. If there is anything else I can help you with to get to the bottom of this problem don't hesitate to ask. Attached is a the gdb output and the backtrace from DDB. Excelent, can you open up the kernel in gdb again. Then do the following: frame 3 print bp With this information I should be able to find the problem. Thanks! Jeff To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: kern/49079: panic: bwrite: buffer is not busy
On Sun, Mar 16, 2003 at 02:46:13AM -0500, Jeff Roberson wrote:
On Sat, 15 Mar 2003, Morten Rodal wrote:
On Fri, Mar 14, 2003 at 06:47:27PM +0100, Morten Rodal wrote:
[snip the parent post]
I just got another one of these. This time it didn't double panic
while syncing the disks. I've been getting this quite often now,
almost daily. If there is anything else I can help you with to get to
the bottom of this problem don't hesitate to ask.
Attached is a the gdb output and the backtrace from DDB.
Excelent, can you open up the kernel in gdb again. Then do the following:
frame 3
print bp
With this information I should be able to find the problem.
--
Morten Rodal
Script started on Sun Mar 16 08:57:26 2003
slurp# gdb -k kernel.3 vmcore.3
GNU gdb 5.2.1 (FreeBSD)
Copyright 2002 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type show copying to see the conditions.
There is absolutely no warranty for GDB. Type show warranty for details.
This GDB was configured as i386-undermydesk-freebsd...
panic: bwrite: buffer is not busy???
panic messages:
---
panic: bwrite: buffer is not busy???
cpuid = 1; lapic.id =
Stack backtrace:
boot() called on cpu#1
syncing disks, buffers remaining... 3452 3452 3451 3451 3449 3448 3448 3448 3448 3448
3448 3448 3448 3448 3448 3448 3448 3448 3448 3448 3448 3448 3448 3448 3448
giving up on 110 buffers
Uptime: 48m16s
Dumping 447 MB
[CTRL-C to abort] [CTRL-C to abort] [CTRL-C to abort] [CTRL-C to abort] [CTRL-C to
abort] [CTRL-C to abort] [CTRL-C to abort] [CTRL-C to abort] [CTRL-C to abort] [CTRL-C
to abort] [CTRL-C to abort] [CTRL-C to abort] [CTRL-C to abort] [CTRL-C to abort]
[CTRL-C to abort] [CTRL-C to abort] [CTRL-C to abort] [CTRL-C to abort] [CTRL-C to
abort] [CTRL-C to abort] [CTRL-C to abort] [CTRL-C to abort] [CTRL-C to abort] [CTRL-C
to abort] [CTRL-C to abort] [CTRL-C to abort] [CTRL-C to abort] [CTRL-C to abort]
[CTRL-C to abort] [CTRL-C to abort] [CTRL-C to abort] [CTRL-C to abort] [CTRL-C to
abort] [CTRL-C to abort] [CTRL-C to abort] [CTRL-C to abort] 16[CTRL-C to abort]
[CTRL-C to abort] [CTRL-C to abort] [CTRL-C to abort] 32[CTRL-C to abort] [CTRL-C to
abort] [CTRL-C to abort] [CTRL-C to abort] [CTRL-C to abort] [CTRL-C to abort] 48 64
80 96 112 128 144 160 176 192 208 224 240 256 272 288 304 320 336 352 368 384 400 416
432
---
#0 doadump () at /usr/src/sys/kern/kern_shutdown.c:239
239 dumping++;
(kgdb) frame 3
#3 0xc02194e2 in bwrite (bp=0xcc9a5fe8) at /usr/src/sys/kern/vfs_bio.c:802
802 panic(bwrite: need chained iodone);
(kgdb) print bp
$1 = (struct buf *) 0xcc9a5fe8
(kgdb) print *bp
$2 = {b_io = {bio_cmd = 2, bio_dev = 0x, bio_disk = 0x0,
bio_blkno = 4188480, bio_offset = 2145681408, bio_bcount = 16384,
bio_data = 0xd219e000 , bio_flags = 0, bio_error = 0, bio_resid = 0,
bio_done = 0xc021d1f0 bufdonebio, bio_driver1 = 0x0, bio_driver2 = 0x0,
bio_caller1 = 0xc39c9400, bio_caller2 = 0xcc9a5fe8, bio_queue = {
tqe_next = 0x0, tqe_prev = 0xc39c940c}, bio_attribute = 0x0,
bio_from = 0x0, bio_to = 0x0, bio_length = 0, bio_completed = 0,
bio_children = 1398, bio_inbed = 0, bio_parent = 0x0, bio_t0 = {sec = 0,
frac = 0}, bio_task = 0, bio_task_arg = 0x0, bio_pblkno = 518876},
b_op = 0xc036e018, b_magic = 280038160,
b_iodone = 0xc0221300 cluster_callback, b_offset = 262144, b_vnbufs = {
tqe_next = 0x0, tqe_prev = 0x0}, b_left = 0x0, b_right = 0x0,
b_vflags = 0, b_freelist = {tqe_next = 0xcc9a5908, tqe_prev = 0xc03a145c},
b_qindex = 0, b_flags = 1677721604, b_xflags = 0 '\0', b_lock = {
lk_interlock = 0xc039b7a4, lk_flags = 0, lk_sharecount = 0,
lk_waitcount = 0, lk_exclusivecount = 0, lk_prio = 80,
lk_wmesg = 0xc034482b bufwait, lk_timo = 0, lk_lockholder = 0x,
lk_newlock = 0x0}, b_bufsize = 16384, b_runningbufspace = 0,
b_kvabase = 0xd219e000 , b_kvasize = 16384, b_lblkno = 16,
b_vp = 0xc41b1a44, b_object = 0x0, b_dirtyoff = 0, b_dirtyend = 16384,
b_rcred = 0x0, b_wcred = 0x0, b_saveaddr = 0xd219e000, b_pager = {
pg_spc = 0x0, pg_reqpage = 0}, b_cluster = {cluster_head = {
tqh_first = 0xccab02f8, tqh_last = 0xccab0420}, cluster_entry = {
tqe_next = 0xccab02f8, tqe_prev = 0xccab0420}}, b_pages = {0xc0f97d08,
0xc0f80c50, 0xc0f92398, 0xc0e9cfe0, 0xc0eefc48, 0xc0efd490, 0xc0a8a3d8,
0xc0f04120, 0xc0a85c68, 0xc0a853b0, 0xc0a3c1f8, 0xc0f1a140, 0xc0de4288,
0xc0f468d0, 0xc0ac3c18, 0xc0a61e60, 0xc0a4fea8, 0xc0f175f0, 0xc0de5638,
0xc0dee680, 0xc0ddeac8, 0xc0f07210, 0xc0a9fe58, 0xc0f462a0, 0xc0dd40e8,
0xc0f3a630, 0xc0ef4178, 0xc0f3dcc0, 0xc0de6b08, 0xc0f3b050, 0xc0f17998,
0xc0dd81e0}, b_npages = 4, b_dep = {lh_first = 0x0}}
(kgdb) slurp# ^Dexit
Script done on Sun Mar 16 08:57:55 2003
pgp0.pgp
