Re: fdimage tool on rc2 cd missing
On Thu, Dec 26, 2002 at 11:38:00PM +0100, Jens Rehsack wrote: > correct me if I'm wrong, but shouldn't be the fdimage tool for creating > disk images under DOS on the first cd of 5.0-RC2 (and later RELEASE)? Yes, fdimage is one of many tools that should be included in the 'tools' directory on the full release ISOs. Someone forgot to add the tools directory to the RC2 ISO. The release candidate ISOs contain just the base bits + packages, if that much. Adding the 'tools' directory should really be an option to "make release" but it isn't yet. It's listed as one of the manual steps in the releng article though. Anyway, you can download the fdimage program from : ftp.freebsd.org/pub/FreeBSD/tools you can see the checklist for what goes on the final CDROM images here: www.freebsd.org/doc/en_US.ISO8859-1/articles/releng - Murray To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ep0 hard lockup during install
On Mon, 30 Dec 2002, Roderick van Domburg wrote: > For three days in a row now I have tried installing the most recent 5.0 > snapshots on my Armada V300 from floppies. I have also tried the RC2 > floppies. I just installed RC2 using a 3C574B with the 'ep' driver; worked just fine aside from needing to re-roll kern.flp and mfsroot.flp to support OLDCARD. -- | 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
5.0-RC1: sysinstall changes disklabels on other slices?
I've seen a few discussions of sysinstall vs disklabels, but this problem looks a little different. I sliced up a 37G disk with 4.7-RELEASE on ad0s1, Win2k on ad0s[23] and ad0s4 empty. I installed grub-0.92, putting the bootloader in the MBR and config files in ad0s1a. Everything worked fine. Then I installed 5.0-RC1 on ad0s4. The next reboot, grub dumped me at the prompt, saying that there were no BSD partitions on ad0s1. It took a while to figure out the problem, but it seems that installing 5.0-RC1 on slice 4 rewrote the disklabel on slice 1. I wiped ad0s4 and reinstalled last night, saving the before and after disklabels. Here's ad0s1 (4.7): # /dev/ad0s1c: type: ESDI disk: ad0s1 label: flags: bytes/sector: 512 sectors/track: 63 tracks/cylinder: 255 sectors/cylinder: 16065 cylinders: 1621 sectors/unit: 26057367 rpm: 3600 interleave: 1 trackskew: 0 cylinderskew: 0 headswitch: 0 # milliseconds track-to-track seek: 0 # milliseconds drivedata: 0 8 partitions: #size offsetfstype [fsize bsize bps/cpg] a: 419430404.2BSD0 0 0 # (Cyl.0 - 261*) b: 2097152 4194304 swap# (Cyl. 261*- 391*) c: 260573670unused0 0 # (Cyl.0 - 1621*) e: 4194304 62914564.2BSD0 0 0 # (Cyl. 391*- 652*) f: 4194304 104857604.2BSD0 0 0 # (Cyl. 652*- 913*) g: 11377303 146800644.2BSD0 0 0 # (Cyl. 913*- 1621*) Here's ad0s4 (empty): # /dev/ad0s4c: type: ESDI disk: ad0s4 label: flags: bytes/sector: 512 sectors/track: 63 tracks/cylinder: 255 sectors/cylinder: 16065 cylinders: 1622 sectors/unit: 26057430 rpm: 3600 interleave: 1 trackskew: 0 cylinderskew: 0 headswitch: 0 # milliseconds track-to-track seek: 0 # milliseconds drivedata: 0 8 partitions: #size offsetfstype [fsize bsize bps/cpg] c: 260574300unused0 0 # (Cyl.0 - 1621) And here's the config for sysinstall: # disk format disk=ad0 partition=existing bootManager=none diskPartitionEditor # disk slices ad0s4-1=ufs 4194304 / 1 # 2G+ soft updates ad0s4-2=swap2097152 none# 1G ad0s4-3=ufs 4194304 /var1 # 2G+ soft updates ad0s4-4=ufs 4194304 /usr1 # 2G+ soft updates ad0s4-5=ufs 0 /home 1 # free + soft updates diskLabelEditor # install system distSetEverything mediaSetCDROM installCommit # install packages package=lynx-2.8.4.1c packageAdd package=sudo-1.6.6 packageAdd After the installation, here's ad0s1 (4.7): # /dev/ad0s1c: type: ESDI disk: ad0s1 label: flags: bytes/sector: 512 sectors/track: 63 tracks/cylinder: 255 sectors/cylinder: 16065 cylinders: 1621 sectors/unit: 26057367 rpm: 3600 interleave: 1 trackskew: 0 cylinderskew: 0 headswitch: 0 # milliseconds track-to-track seek: 0 # milliseconds drivedata: 0 8 partitions: #size offsetfstype [fsize bsize bps/cpg] a: 41943040unused0 0 # (Cyl.0 - 261*) b: 2097152 4194304unused0 0 # (Cyl. 261*- 391*) c: 260573670unused0 0 # (Cyl.0 - 1621*) e: 4194304 6291456unused0 0 # (Cyl. 391*- 652*) f: 4194304 10485760unused0 0 # (Cyl. 652*- 913*) g: 11377303 14680064unused0 0 # (Cyl. 913*- 1621*) And ad0s4 (5.0-RC1): # /dev/ad0s4c: type: ESDI disk: ad0s4 label: flags: bytes/sector: 512 sectors/track: 63 tracks/cylinder: 255 sectors/cylinder: 16065 cylinders: 1622 sectors/unit: 26057430 rpm: 3600 interleave: 1 trackskew: 0 cylinderskew: 0 headswitch: 0 # milliseconds track-to-track seek: 0 # milliseconds drivedata: 0 8 partitions: #size offsetfstype [fsize bsize bps/cpg] a: 419430404.2BSD0 0 0 # (Cyl.0 - 261*) b: 2097152 4194304 swap# (Cyl. 261*- 391*) c: 260574300unused0 0 # (Cyl.0 - 1621) d: 4194304 62914564.2BSD0 0 0 # (Cyl. 391*- 652*) e: 4194304 104857604.2BSD0 0 0 # (Cyl. 652*- 913*) f: 11377366 146800644.2BSD0 0 0 # (Cyl. 913*- 1621*) Notice that all the fstype values on ad0s1 have changed to 'unused' - this borks grub, because it can't find any FFS filesystems. So I installed boot0 (which didn't have any problem with the missing fstypes), rebooted into 4.7 and fixed things with disklabel -e. Once grub could see BSD partitions, I reinstalled it in the MBR and everything work
Re: Problem with /dev/stdout in a chroot environment.
I'm sorry, I have realised that nothing in the /dev directory is being
populated in the chroot by the buildworld attempt, so there is
something problematic further down the chain.
I'm an idiot - thanks and sorry for the bother.
On Mon, Dec 30, 2002 at 08:54:14PM -0500, Robert Watson wrote:
>
> On Mon, 30 Dec 2002, Marc Butler wrote:
>
> > I'm currently trying to build CURRENT (DEC 29 2002) within a chroot
> > environment under CURRENT (DEC 17 2002). Presently I am stuck on an
> > error which appears to be related to /dev/stdout in a chroot environment
> > (devfs?).
>
> Could you provide a bit more detail on what's actually in the chroot
> directory? Have you mounted devfs in chroot/dev, or did you manually
> stick in the device nodes? In -STABLE, /dev/std* were actual device
> nodes, whereas in -CURRENT, devfs makes them symlinks to fd/{0,1,2}, so
> the details here are important...
>
> Robert N M Watson FreeBSD Core Team, TrustedBSD Projects
> [EMAIL PROTECTED] Network Associates Laboratories
>
--
Marc Butler <[EMAIL PROTECTED]>
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: My wi(4) ate itself (or Fun with no memory).
In message: <[EMAIL PROTECTED]> Michael Ranner <[EMAIL PROTECTED]> writes: : Am Montag, 30. Dezember 2002 23:10 schrieb Lee Damon: : > I have the same problems on an IBM T30 with integrated wi running : > 4.7-STABLE. In fact, I've had this problem since 4.5 (which is where I : > started on this system.) : : I think the "wi0: timeout in wi_cmd 0x; event status 0x8000" : messages started around 4.4, 4.5 or so. With my old FreeBSD 4 I had no : "visible" problems, but after upgrading to 4.7 I have tons of wi_timeout's : : I fixed it with: : : 1359c1359 : < DELAY(WI_DELAY); : --- : > /*DELAY(WI_DELAY);*/ This delay is needed on far too many cards to just delete it. : 1363,1364c1363,1364 : < device_printf(sc->dev, "timeout in wi_seek to %x/%x; last : status %x\n", : < id, off, status); : --- : > /*device_printf(sc->dev, "timeout in wi_seek to %x/%x; last : status %x\n", : > id, off, status);*/ this isn't a fix. : The big problem was the "DELAY", because this call freezes the system and that : was not acceptable for a router, but I also increased the value of the : surrounding loop. The big problem is that we have a horrible reset policy in the wi driver. When it gets into this state, we're screwing the system into the ground in the driver. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: No panics on the bento cluster!
On Mon, Dec 30, 2002 at 10:19:32PM -0500, Brent Verner wrote: > [2002-12-30 18:53] Kris Kennaway said: > | I just wanted to share the good news that since updating to matt's > | vmspace fix (over a week ago), there have been no panics on the bento > | cluster (21 machines of 3 architectures running 5.0-RC, under constant > | heavy load, and despite the close proximity of Peter Wemm in the > | datacenter for a few hours). This is quite unusual, and it means that > | either 5.0 is shaping up well for the release, or the whole house of > | cards is about to come crashing down :-) > > Speaking of bento... > > I noticed that a nice artifact of the bento ports test/build system > are the fresh port packages. Is it acceptable to use that machine > (http://bento.freebsd.org) as PACKAGESITE for pkg_add? I've done it > a few times, but don't want to (ab)use it if the packages are not > there for general package installation use. It's fine when it works, which is most of the time except when it doesn't :-) (e.g. if the build has been interrupted, fails catastrophically, or produces broken packages) Kris msg49468/pgp0.pgp Description: PGP signature
problem with nullfs
A nullfs mounted target cannot be umounted if another target is
mounted from the same source. Maybe it has something to do with
the LOR in the first umount... I'll see if I can fix this later
in the week if it hasn't already been fixed.
scratch# uname -a
FreeBSD scratch.rcfile.org 5.0-CURRENT FreeBSD 5.0-CURRENT #27: Mon Dec 30 14:28
:24 EST 2002 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/SCRATCH i386
scratch# mount -t nullfs -oro /usr/ports /jail/10.0.0.75/usr/ports
scratch# umount /jail/10.0.0.75/usr/ports
lock order reversal
1st 0xc523cce0 process lock (process lock) @ /usr/src/sys/kern/vfs_mount.c:1143
2nd 0xc5289b34 filedesc structure (filedesc structure) @ /usr/src/sys/kern/vfs_
mount.c:1150
Debugger("witness_lock")
Stopped at Debugger+0x54: xchgl %ebx,in_Debugger.0
db> trace
Debugger(c0498ff5,c5289b34,c04cf6a9,c04cf6a9,c04d8df6) at Debugger+0x54
witness_lock(c5289b34,8,c04d8df6,47e,c04d934f) at witness_lock+0x667
_mtx_lock_flags(c5289b34,0,c04d8df6,47e,0) at _mtx_lock_flags+0xb1
checkdirs(c546a9fc,c546ad50,1,c5236540,0) at checkdirs+0xc8
dounmount(c5366800,0,c5236540,bfbffd67,0) at dounmount+0x188
unmount(c5236540,e1a43d10,c04ec1f2,407,2) at unmount+0xcc
syscall(2f,2f,2f,809ab0e,80b3b3e) at syscall+0x28e
Xint0x80_syscall() at Xint0x80_syscall+0x1d
--- syscall (22, FreeBSD ELF32, unmount), eip = 0x804b3ef, esp = 0xbfbff71c, ebp
= 0xbfbff798 ---
db> cont
scratch# mount -t nullfs -oro /usr/ports /jail/10.0.0.75/usr/ports
scratch# umount /jail/10.0.0.75/usr/ports
scratch# mount -t nullfs -oro /usr/ports /jail/10.0.0.75/usr/ports
scratch# umount /jail/10.0.0.75/usr/ports
scratch# mount -t nullfs -oro /usr/ports /jail/10.0.0.75/usr/ports
scratch# mount -t nullfs -oro /usr/ports /jail/10.0.0.76/usr/ports
scratch# umount /jail/10.0.0.75/usr/ports
umount: unmount of /jail/10.0.0.75/usr/ports failed: Device busy
scratch# umount /jail/10.0.0.76/usr/ports
umount: unmount of /jail/10.0.0.76/usr/ports failed: Device busy
cheers.
b
--
"Develop your talent, man, and leave the world something. Records are
really gifts from people. To think that an artist would love you enough
to share his music with anyone is a beautiful thing." -- Duane Allman
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: No panics on the bento cluster!
[2002-12-30 18:53] Kris Kennaway said: | I just wanted to share the good news that since updating to matt's | vmspace fix (over a week ago), there have been no panics on the bento | cluster (21 machines of 3 architectures running 5.0-RC, under constant | heavy load, and despite the close proximity of Peter Wemm in the | datacenter for a few hours). This is quite unusual, and it means that | either 5.0 is shaping up well for the release, or the whole house of | cards is about to come crashing down :-) Speaking of bento... I noticed that a nice artifact of the bento ports test/build system are the fresh port packages. Is it acceptable to use that machine (http://bento.freebsd.org) as PACKAGESITE for pkg_add? I've done it a few times, but don't want to (ab)use it if the packages are not there for general package installation use. thanks. b -- "Develop your talent, man, and leave the world something. Records are really gifts from people. To think that an artist would love you enough to share his music with anyone is a beautiful thing." -- Duane Allman To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: spec_getpages I/O read failure on md0
I was finally able to reproduce this. Here are some offset values: Dec 30 10:55:07 lizzy kernel: spec_getpages:(md0) I/O read failure: (error=22) b p 0xce5fb488 vp 0xc41e4708 Dec 30 10:55:07 lizzy kernel: size: 6144, resid: 6144, a_count: 6124, valid: 0x0 Dec 30 10:55:07 lizzy kernel: nread: 0, reqpage: 0, pindex: 0, pcount: 2 Dec 30 10:55:07 lizzy kernel: offset: 20316160 Dec 30 13:29:07 lizzy kernel: spec_getpages:(md0) I/O read failure: (error=22) b p 0xce5fa630 vp 0xc41e4708 Dec 30 13:29:07 lizzy kernel: size: 6144, resid: 6144, a_count: 6124, valid: 0x0 Dec 30 13:29:07 lizzy kernel: nread: 0, reqpage: 0, pindex: 0, pcount: 2 Dec 30 13:29:07 lizzy kernel: offset: 28729344 Dec 30 16:04:31 lizzy kernel: spec_getpages:(md0) I/O read failure: (error=22) b p 0xce5f8fe0 vp 0xc41e4708 Dec 30 16:04:31 lizzy kernel: size: 6144, resid: 6144, a_count: 6124, valid: 0x0 Dec 30 16:04:31 lizzy kernel: nread: 0, reqpage: 0, pindex: 0, pcount: 2 Dec 30 16:04:32 lizzy kernel: offset: 20316160 Dec 30 16:05:47 lizzy kernel: spec_getpages:(md0) I/O read failure: (error=22) b p 0xce5f9ca0 vp 0xc41e4708 Dec 30 16:05:47 lizzy kernel: size: 14848, resid: 14848, a_count: 14404, valid: 0x0 Dec 30 16:05:47 lizzy kernel: nread: 0, reqpage: 0, pindex: 0, pcount: 4 Dec 30 16:05:47 lizzy kernel: offset: 17874944 Does this help? -- Jos Backus _/ _/_/_/ Sunnyvale, CA _/ _/ _/ _/ _/_/_/ _/ _/ _/_/ jos at catnook.com_/_/ _/_/_/ require 'std/disclaimer' To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: No panics on the bento cluster!
On Mon, Dec 30, 2002 at 06:53:52PM -0800, Kris Kennaway wrote: > I just wanted to share the good news that since updating to matt's > vmspace fix (over a week ago), there have been no panics on the bento > cluster (21 machines of 3 architectures running 5.0-RC, under constant > heavy load, and despite the close proximity of Peter Wemm in the > datacenter for a few hours). This is quite unusual, and it means that > either 5.0 is shaping up well for the release, or the whole house of > cards is about to come crashing down :-) Actually, come to think of it bento itself is panicking a lot instead (it's a 4.x SMP machine). Maybe I should upgrade it to 5.0 :-) Kris msg49464/pgp0.pgp Description: PGP signature
Re: My wi(4) ate itself (or Fun with no memory).
In message: <[EMAIL PROTECTED]> Juli Mallett <[EMAIL PROTECTED]> writes: : /var/log/messages:Dec 30 17:11:35 luna kernel: wi0: failed to allocate 1594 bytes on :NIC : : Like those? Those are usually an indication of no interrupts. Memory is allocated when packets are sent and deallocated in the ISR. No ISR, no deallocation. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
No panics on the bento cluster!
I just wanted to share the good news that since updating to matt's vmspace fix (over a week ago), there have been no panics on the bento cluster (21 machines of 3 architectures running 5.0-RC, under constant heavy load, and despite the close proximity of Peter Wemm in the datacenter for a few hours). This is quite unusual, and it means that either 5.0 is shaping up well for the release, or the whole house of cards is about to come crashing down :-) Kris msg49462/pgp0.pgp Description: PGP signature
Re: Problem with /dev/stdout in a chroot environment.
On Mon, 30 Dec 2002, Marc Butler wrote:
> I'm currently trying to build CURRENT (DEC 29 2002) within a chroot
> environment under CURRENT (DEC 17 2002). Presently I am stuck on an
> error which appears to be related to /dev/stdout in a chroot environment
> (devfs?).
Could you provide a bit more detail on what's actually in the chroot
directory? Have you mounted devfs in chroot/dev, or did you manually
stick in the device nodes? In -STABLE, /dev/std* were actual device
nodes, whereas in -CURRENT, devfs makes them symlinks to fd/{0,1,2}, so
the details here are important...
Robert N M Watson FreeBSD Core Team, TrustedBSD Projects
[EMAIL PROTECTED] Network Associates Laboratories
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: My wi(4) ate itself (or Fun with no memory).
* De: Taavi Talvik <[EMAIL PROTECTED]> [ Data: 2002-12-30 ] [ Subjecte: Re: My wi(4) ate itself (or Fun with no memory). ] > On Mon, 30 Dec 2002, M. Warner Losh wrote: > > > In message: <[EMAIL PROTECTED]> > > Juli Mallett <[EMAIL PROTECTED]> writes: > > : I ran some stuff overnight which exhausted my system's memory fairly well, > > : and was also thrashing around on my network, and I woke up to find that my > > : wi(4) blew up more or less: > > : > > : wi0: watchdog timeout > > : wi0: timeout in wi_cmd 0x0002; event status 0x8000 > > : wi0: timeout in wi_cmd 0x; event status 0x8000 > > : wi0: wi_cmd: busy bit won't clear. > > > > The firmware on your card hung hard. The wi driver doesn't deal with > > that at all well (although one could rightly argue it should). Why > > the firmware hung hard, I cannot say. > > I got the similiar(?) hang on perfectly working system, when I loaded > firewire driver. There was some additional message about exchausting > memory somewhere (probably something related to wi memory, don't remember, > as i am writing this from memory). /var/log/messages:Dec 30 17:06:48 luna kernel: wi0: failed to allocate 1594 bytes on NIC /var/log/messages:Dec 30 17:09:14 luna kernel: wi0: failed to allocate 1594 bytes on NIC /var/log/messages:Dec 30 17:11:34 luna kernel: wi0: failed to allocate 1594 bytes on NIC /var/log/messages:Dec 30 17:11:34 luna kernel: wi0: failed to allocate 1594 bytes on NIC /var/log/messages:Dec 30 17:11:35 luna kernel: wi0: failed to allocate 1594 bytes on NIC /var/log/messages:Dec 30 17:11:35 luna kernel: wi0: failed to allocate 1594 bytes on NIC Like those? -- Juli Mallett <[EMAIL PROTECTED]> AIM: BSDFlata IRC: juli@EFnet#flata OpenDarwin, Mono, FreeBSD Developer. ircd-hybrid Developer, EFnet addict. FreeBSD on MIPS-Anything on FreeBSD. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: My wi(4) ate itself (or Fun with no memory).
On Mon, 30 Dec 2002, M. Warner Losh wrote: > In message: <[EMAIL PROTECTED]> > Juli Mallett <[EMAIL PROTECTED]> writes: > : I ran some stuff overnight which exhausted my system's memory fairly well, > : and was also thrashing around on my network, and I woke up to find that my > : wi(4) blew up more or less: > : > : wi0: watchdog timeout > : wi0: timeout in wi_cmd 0x0002; event status 0x8000 > : wi0: timeout in wi_cmd 0x; event status 0x8000 > : wi0: wi_cmd: busy bit won't clear. > > The firmware on your card hung hard. The wi driver doesn't deal with > that at all well (although one could rightly argue it should). Why > the firmware hung hard, I cannot say. I got the similiar(?) hang on perfectly working system, when I loaded firewire driver. There was some additional message about exchausting memory somewhere (probably something related to wi memory, don't remember, as i am writing this from memory). If it's interesting i'll try to repeat it? best regards, taavi To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: My wi(4) ate itself (or Fun with no memory).
> Date: Mon, 30 Dec 2002 23:06:50 +0100 > From: Christian Brueffer <[EMAIL PROTECTED]> > Sender: [EMAIL PROTECTED] > > > --x+6KMIRAuhnl3hBn > Content-Type: text/plain; charset=us-ascii > Content-Disposition: inline > Content-Transfer-Encoding: quoted-printable > > On Mon, Dec 30, 2002 at 11:36:45AM -0800, Juli Mallett wrote: > > Hey, > >=20 > > I ran some stuff overnight which exhausted my system's memory fairly well, > > and was also thrashing around on my network, and I woke up to find that my > > wi(4) blew up more or less: > >=20 > > wi0: watchdog timeout > > wi0: timeout in wi_cmd 0x0002; event status 0x8000 > > wi0: timeout in wi_cmd 0x; event status 0x8000 > > wi0: wi_cmd: busy bit won't clear. > > wi0: wi_cmd: busy bit won't clear. > > wi0: init failed > > wi0: wi_cmd: busy bit won't clear. > > wi0: wi_cmd: busy bit won't clear. > > wi0: wi_cmd: busy bit won't clear. > > wi0: wi_cmd: busy bit won't clear. > > wi0: wi_cmd: busy bit won't clear. > > wi0: wi_cmd: busy bit won't clear. > > wi0: wi_cmd: busy bit won't clear. > > wi0: wi_cmd: busy bit won't clear. > > wi0: wi_cmd: busy bit won't clear. > > wi0: wi_cmd: busy bit won't clear. > > wi0: wi_cmd: busy bit won't clear. > > wi0: wi_cmd: busy bit won't clear. > > wi0: wi_cmd: busy bit won't clear. > > wi0: wi_cmd: busy bit won't clear. > > wi0: wi_cmd: busy bit won't clear. > > wi0: wi_cmd: busy bit won't clear. > > wi0: wi_cmd: busy bit won't clear. > > wi0: wi_cmd: busy bit won't clear. > > wi0: wi_cmd: busy bit won't clear. > > wi0: wi_cmd: busy bit won't clear. > > wi0: wi_cmd: busy bit won't clear. > > wi0: wi_cmd: busy bit won't clear. > > wi0: failed to allocate 1594 bytes on NIC > > wi0: tx buffer allocation failed > > wi0: wi_cmd: busy bit won't clear. > > wi0: failed to allocate 1594 bytes on NIC > > wi0: mgmt. buffer allocation failed > > Expensive timeout(9) function: 0xc02aefa0(0) 127.445894221 > > wi0: timeout in wi_seek to 0/0; last status 4000 > > wi0: timeout in wi_seek to 0/44; last status 4044 > > wi0: wi_cmd: busy bit won't clear. > > wi0: xmit failed > > Expensive timeout(9) function: 0xc02cfde0(0xc1a08ccc) 7.384429976 > > wi0: watchdog timeout > > wi0: wi_cmd: busy bit won't clear. > > wi0: wi_cmd: busy bit won't clear. > > wi0: wi_cmd: busy bit won't clear. > > wi0: wi_cmd: busy bit won't clear. > > wi0: init failed > > wi0: wi_cmd: busy bit won't clear. > > wi0: wi_cmd: busy bit won't clear. > > wi0: wi_cmd: busy bit won't clear. > > wi0: wi_cmd: busy bit won't clear. > > wi0: wi_cmd: busy bit won't clear. > > wi0: wi_cmd: busy bit won't clear. > > wi0: wi_cmd: busy bit won't clear. > > wi0: wi_cmd: busy bit won't clear. > > wi0: wi_cmd: busy bit won't clear. > > wi0: wi_cmd: busy bit won't clear. > > wi0: wi_cmd: busy bit won't clear. > > wi0: wi_cmd: busy bit won't clear. > > wi0: wi_cmd: busy bit won't clear. > > wi0: wi_cmd: busy bit won't clear. > > wi0: wi_cmd: busy bit won't clear. > > wi0: wi_cmd: busy bit won't clear. > > wi0: wi_cmd: busy bit won't clear. > > wi0: wi_cmd: busy bit won't clear. > > wi0: wi_cmd: busy bit won't clear. > > wi0: wi_cmd: busy bit won't clear. > > wi0: wi_cmd: busy bit won't clear. > > wi0: wi_cmd: busy bit won't clear. > > wi0: failed to allocate 1594 bytes on NIC > > wi0: tx buffer allocation failed > > wi0: wi_cmd: busy bit won't clear. > > wi0: failed to allocate 1594 bytes on NIC > > wi0: mgmt. buffer allocation failed > > Expensive timeout(9) function: 0xc02aefa0(0) 135.098850348 > > wi0: timeout in wi_seek to 0/0; last status 4000 > > wi0: timeout in wi_seek to 0/44; last status 4044 > > wi0: wi_cmd: busy bit won't clear. > > wi0: xmit failed > >=20 > > Was how it started, and then a lot more of the 'busy bit won't clear' > > messages. I ejected the card after de-b0rking the rest of the system, and > > was able to bring it back up fine, but thought maybe someone might have s= > ome > > insight into how exactly my wi(4) blew up, and whether this is an accepta= > ble > > failure case :) > >=20 > > Thanx, > > juli. > > --=20 > > Juli Mallett <[EMAIL PROTECTED]> > > AIM: BSDFlata IRC: juli@EFnet#flata > > OpenDarwin, Mono, FreeBSD Developer. > > ircd-hybrid Developer, EFnet addict. > > FreeBSD on MIPS-Anything on FreeBSD. > >=20 > > To Unsubscribe: send mail to [EMAIL PROTECTED] > > with "unsubscribe freebsd-current" in the body of the message > >=20 > >=20 > > I get those messages when running dstumbler and then trying to do other stu= > ff > with the device. > The bad thing is, that the chip is integrated in my notebook so i can't sim= > ply > take it out and back in again :-) > Is there any other way to reinitialize the card? I see a possible fix posted by Michael Ranner and will try it next week. I have discovered that the problem seems to occur only when I am at work and receive signals from an encrypted access point to which I can't (and don't want to) associate. Something about this situation triggers the problem in FreeBSD while under Windows I am simply notified t
[no subject]
suscribe To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Problem with /dev/stdout in a chroot environment.
I'm currently trying to build CURRENT (DEC 29 2002) within a chroot environment under CURRENT (DEC 17 2002). Presently I am stuck on an error which appears to be related to /dev/stdout in a chroot environment (devfs?). Specifically writing to /dev/stdout does not work (specifically: genassym.sh). For example (my default shell is tcsh, chroot directory is "chroot"): bugs.ttyp0% sudo chroot chroot # echo "test" > /dev/stdout # echo "test" > /dev/tty # echo "test" > /dev/fd/1 # As you can see none of these result in test written to the shell. Additionally /bin/sh sounds off if specifically started in place of tcsh: bugs.ttyp0% sudo chroot chroot /bin/sh sh: can't access tty; job control turned off In the chroot environment /dev looks to be broken when compared to the /dev system in the hosting environment: bugs.ttyp0% devnum chroot/dev/fd/1 chroot/dev/fd/1: dev = 4/11 bugs.ttyp0% devnum /dev/fd/1 /dev/fd/1: dev = 255/67108864 (character) rdev = 22/1 I'm not sure whether this is the result something that I have done incorrectly, or if it is a bug. I have made a cursory look at jail, but it appears to be _overkill_ for the task. -- Marc Butler <[EMAIL PROTECTED]> To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: missed disk nodes
On Mon, 30 Dec 2002 [EMAIL PROTECTED] wrote: > Can you please: > dd if=/dev/da2 bs=64k | uuencode - foo | mail [EMAIL PROTECTED] ^^ You probably should add count=1 there, otherwise it's going to be a big email. -Nate To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: dri-devel - HEADS-UP
From: "Chuck Robey" <[EMAIL PROTECTED]> Sent: Monday, December 30, 2002 5:02 PM > The moral is, I think you need to rebuild/reinstall dri-devel if you're > running FreeBSD-current. I have found that it's generally a good idea to rebuild any modules you have from ports (in my case it's ltmdm and radeon) when you upgrade the kernel. Especially with -CURRENT, the module interface could change at any time. Specifically, I had the same issue you did with ltmdm early last week, with the same solution (rebuild the port). ltmdm's pkg-message specifically tells you you'll have to do this, in fact. --K To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: My wi(4) ate itself (or Fun with no memory).
Am Montag, 30. Dezember 2002 23:10 schrieb Lee Damon: > I have the same problems on an IBM T30 with integrated wi running > 4.7-STABLE. In fact, I've had this problem since 4.5 (which is where I > started on this system.) I think the "wi0: timeout in wi_cmd 0x; event status 0x8000" messages started around 4.4, 4.5 or so. With my old FreeBSD 4 I had no "visible" problems, but after upgrading to 4.7 I have tons of wi_timeout's I fixed it with: 1359c1359 < DELAY(WI_DELAY); --- > /*DELAY(WI_DELAY);*/ 1363,1364c1363,1364 < device_printf(sc->dev, "timeout in wi_seek to %x/%x; last status %x\n", < id, off, status); --- > /*device_printf(sc->dev, "timeout in wi_seek to %x/%x; last status %x\n", > id, off, status);*/ The big problem was the "DELAY", because this call freezes the system and that was not acceptable for a router, but I also increased the value of the surrounding loop. > > > wi0: watchdog timeout > > > wi0: tiwi0: wi_cmeout in wi_cmd 0x; event status 0x8000 > > > wi0: wi_cmd: busy bit won't clear. > > > wi0: init failed ... I've seen this kind of problems with my Netgear, D-Link (both Prism2.5) and US-Robotis (Prism2) cards in access point mode. I have no such messages and problems in ad-hoc mode. Regards, /\/\ichael Ranner [EMAIL PROTECTED] - [EMAIL PROTECTED] - [EMAIL PROTECTED] -- JAWA Management Software GmbH - http://www.jawa.at/ Liebenauer Hauptstrasse 2oo - A-8041 Graz Tel +43 316 403274 21 - Fax +43 316 403274 10 -- Mariazell Online - http://www.mariazell.at/ -- -BEGIN GEEK CODE BLOCK- GIT/CS/AT dx(-) s+:(++:) a- C++ UBLVS$ P++>+++$ L-(+)$ E--- W+++$ N+(++) o-- K- w--()$ O-(--) M@ V-(--) PS+>++ PE(-) Y+ PGP(-) t+ 5+ X+++() R* tv++ b+(++) DI++ D-(--) G- e h--(*) r++ y? --END GEEK CODE BLOCK-- To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
ep0 hard lockup during install
Hello, For three days in a row now I have tried installing the most recent 5.0 snapshots on my Armada V300 from floppies. I have also tried the RC2 floppies. Unfortunately, the system freezes up solid when it configures ep0. I have a DHCP server here but manually entering the IP configuration results in the same hard lockup. No error messages of any kind are given, I can't switch to pty2 and the kernel doesn't panic. It just locks up completely and indefinitely. ep0 is a PCMCIA card. I have two of such cards, one being a 3C589, the other a 3CXE589DC. Both cards produce the same result but worked fine on 4-STABLE. I have tried reinserting the cards both before and during the network configuration and have also fiddled with the USB legacy support setting in the system BIOS (not too much options to fiddle with unfortunately), but to no avail. The kernel messages on pty1 and debug messages on pty2 show no deviating messages. Hope you can help! Roderick To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: My wi(4) ate itself (or Fun with no memory).
* De: Christian Brueffer <[EMAIL PROTECTED]> [ Data: 2002-12-30 ] [ Subjecte: Re: My wi(4) ate itself (or Fun with no memory). ] > The bad thing is, that the chip is integrated in my notebook so i can't simply > take it out and back in again :-) > Is there any other way to reinitialize the card? I think if we see something which is obviously a dead card we can probably restart the card at a cardbus/... level, but I have no idea how hard this is to do in practice, and Warner would probably beat me over the head for thinking it's that simple :) -- Juli Mallett <[EMAIL PROTECTED]> AIM: BSDFlata IRC: juli@EFnet#flata OpenDarwin, Mono, FreeBSD Developer. ircd-hybrid Developer, EFnet addict. FreeBSD on MIPS-Anything on FreeBSD. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: My wi(4) ate itself (or Fun with no memory).
I have the same problems on an IBM T30 with integrated wi running 4.7-STABLE. In fact, I've had this problem since 4.5 (which is where I started on this system.) nomad > On Mon, Dec 30, 2002 at 11:36:45AM -0800, Juli Mallett wrote: > > Hey, > >=20 > > I ran some stuff overnight which exhausted my system's memory fairly well, > > and was also thrashing around on my network, and I woke up to find that my > > wi(4) blew up more or less: > >=20 > > wi0: watchdog timeout > > wi0: timeout in wi_cmd 0x0002; event status 0x8000 > > wi0: timeout in wi_cmd 0x; event status 0x8000 > > wi0: wi_cmd: busy bit won't clear. > > wi0: wi_cmd: busy bit won't clear. > > wi0: init failed > > wi0: wi_cmd: busy bit won't clear. > > wi0: wi_cmd: busy bit won't clear. > > wi0: wi_cmd: busy bit won't clear. > > wi0: wi_cmd: busy bit won't clear. > > wi0: wi_cmd: busy bit won't clear. > > wi0: wi_cmd: busy bit won't clear. > > wi0: wi_cmd: busy bit won't clear. > > wi0: wi_cmd: busy bit won't clear. > > wi0: wi_cmd: busy bit won't clear. > > wi0: wi_cmd: busy bit won't clear. > > wi0: wi_cmd: busy bit won't clear. > > wi0: wi_cmd: busy bit won't clear. > > wi0: wi_cmd: busy bit won't clear. > > wi0: wi_cmd: busy bit won't clear. > > wi0: wi_cmd: busy bit won't clear. > > wi0: wi_cmd: busy bit won't clear. > > wi0: wi_cmd: busy bit won't clear. > > wi0: wi_cmd: busy bit won't clear. > > wi0: wi_cmd: busy bit won't clear. > > wi0: wi_cmd: busy bit won't clear. > > wi0: wi_cmd: busy bit won't clear. > > wi0: wi_cmd: busy bit won't clear. > > wi0: failed to allocate 1594 bytes on NIC > > wi0: tx buffer allocation failed > > wi0: wi_cmd: busy bit won't clear. > > wi0: failed to allocate 1594 bytes on NIC > > wi0: mgmt. buffer allocation failed > > Expensive timeout(9) function: 0xc02aefa0(0) 127.445894221 > > wi0: timeout in wi_seek to 0/0; last status 4000 > > wi0: timeout in wi_seek to 0/44; last status 4044 > > wi0: wi_cmd: busy bit won't clear. > > wi0: xmit failed > > Expensive timeout(9) function: 0xc02cfde0(0xc1a08ccc) 7.384429976 > > wi0: watchdog timeout > > wi0: wi_cmd: busy bit won't clear. > > wi0: wi_cmd: busy bit won't clear. > > wi0: wi_cmd: busy bit won't clear. > > wi0: wi_cmd: busy bit won't clear. > > wi0: init failed > > wi0: wi_cmd: busy bit won't clear. > > wi0: wi_cmd: busy bit won't clear. > > wi0: wi_cmd: busy bit won't clear. > > wi0: wi_cmd: busy bit won't clear. > > wi0: wi_cmd: busy bit won't clear. > > wi0: wi_cmd: busy bit won't clear. > > wi0: wi_cmd: busy bit won't clear. > > wi0: wi_cmd: busy bit won't clear. > > wi0: wi_cmd: busy bit won't clear. > > wi0: wi_cmd: busy bit won't clear. > > wi0: wi_cmd: busy bit won't clear. > > wi0: wi_cmd: busy bit won't clear. > > wi0: wi_cmd: busy bit won't clear. > > wi0: wi_cmd: busy bit won't clear. > > wi0: wi_cmd: busy bit won't clear. > > wi0: wi_cmd: busy bit won't clear. > > wi0: wi_cmd: busy bit won't clear. > > wi0: wi_cmd: busy bit won't clear. > > wi0: wi_cmd: busy bit won't clear. > > wi0: wi_cmd: busy bit won't clear. > > wi0: wi_cmd: busy bit won't clear. > > wi0: wi_cmd: busy bit won't clear. > > wi0: failed to allocate 1594 bytes on NIC > > wi0: tx buffer allocation failed > > wi0: wi_cmd: busy bit won't clear. > > wi0: failed to allocate 1594 bytes on NIC > > wi0: mgmt. buffer allocation failed > > Expensive timeout(9) function: 0xc02aefa0(0) 135.098850348 > > wi0: timeout in wi_seek to 0/0; last status 4000 > > wi0: timeout in wi_seek to 0/44; last status 4044 > > wi0: wi_cmd: busy bit won't clear. > > wi0: xmit failed > >=20 > > Was how it started, and then a lot more of the 'busy bit won't clear' > > messages. I ejected the card after de-b0rking the rest of the system, and > > was able to bring it back up fine, but thought maybe someone might have s= > ome > > insight into how exactly my wi(4) blew up, and whether this is an accepta= > ble > > failure case :) > >=20 > > Thanx, > > juli. > > --=20 > > Juli Mallett <[EMAIL PROTECTED]> > > AIM: BSDFlata IRC: juli@EFnet#flata > > OpenDarwin, Mono, FreeBSD Developer. > > ircd-hybrid Developer, EFnet addict. > > FreeBSD on MIPS-Anything on FreeBSD. > >=20 > > To Unsubscribe: send mail to [EMAIL PROTECTED] > > with "unsubscribe freebsd-current" in the body of the message > >=20 > >=20 > > I get those messages when running dstumbler and then trying to do other stu= > ff > with the device. > The bad thing is, that the chip is integrated in my notebook so i can't sim= > ply > take it out and back in again :-) > Is there any other way to reinitialize the card? > > - Christian > > --=20 nomad --- - Lee "nomad" Damon - \ play: [EMAIL PROTECTED]or castle!nomad \ work: [EMAIL PROTECTED] \ /\ Seneschal, Castle PAUS./ \ "Celebrate Diversity" /
dri-devel - HEADS-UP
To those of you running the radeon.ko dri module from the ports (ports/graphics/dri-devel) IF YOU'RE RUNNING CURRENT then you might want to listen up. I just did a rebuild of the system for the first time in about 6 days, and my system rebooted immediately when XFree86 attempted loading the radeon.ko. I always rebuild and reinstall the modules when I do the kernel, but I also always take extra care to copy the ports version of radeon.ko over the one built/installed during the modules build, so I am completely certain that I was using the one from the ports. I reverified that on reboot. While I'm not totally certain it was the dri-devel, I rebuilt it again (it used the same sources as before from ports, on the new kernel sources from /usr/src/sys) and next time, used that to load. Result this time was just fine. I did check, the module binary had changed size (gotten a bit smaller). I don't know for sure if that is from a change in the compiler or a change in kernel sources (probably both). I'd previously built the dri-devel port with the gcc 3.2 compiler, it's in a new rev now. The moral is, I think you need to rebuild/reinstall dri-devel if you're running FreeBSD-current. If anyone can either show I'm wrong, or verify my experience, if you'd post your results you'd be doing everyone a favor. I won't mind being proven wrong. Chuck Robey | Interests include C & Java programming, FreeBSD, [EMAIL PROTECTED] | electronics, communications, and SF/Fantasy. New Year's Resolution: I will not sphroxify gullible people into looking up fictitious words in the dictionary. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: mount_portalfs broken in 5.0-RC2
Am Montag, 30. Dezember 2002 22:58 schrieben Sie: > * De: Michael Ranner <[EMAIL PROTECTED]> [ Data: 2002-12-30 ] > [ Subjecte: mount_portalfs broken in 5.0-RC2 ] > > > 1.) > > > > After mounting the portalfs, > > > > # cat /p/tcp/www.jawa.at/21 > > 220 ftp.jawa.at FTP server (ftpd) ready. > > ^C > > > > portalfs hangs, and cat did not return on ^C or ^Z > > I suspect this is more post-KSE signal breakage. I've seen problems with > interrupting stuff that's in the kernel to an absurd degre, but I kinda > hoped it was a local change at fault. But could this explain the problem with "cat /p/telnet" which should return file does not exists. I forgot, I have the same problem with the rfilter/wfilter code, for the first time cat /p/http://www.jawa.at/index.php does work, but the process did not exit as expected and as it works under 4.7-p2. Cat did not return and mount_portalfs freezes. -- /\/\ichael Ranner [EMAIL PROTECTED] - [EMAIL PROTECTED] - [EMAIL PROTECTED] -- JAWA Management Software GmbH - http://www.jawa.at/ Liebenauer Hauptstrasse 2oo - A-8041 Graz Tel +43 316 403274 21 - Fax +43 316 403274 10 -- Mariazell Online - http://www.mariazell.at/ -- -BEGIN GEEK CODE BLOCK- GIT/CS/AT dx(-) s+:(++:) a- C++ UBLVS$ P++>+++$ L-(+)$ E--- W+++$ N+(++) o-- K- w--()$ O-(--) M@ V-(--) PS+>++ PE(-) Y+ PGP(-) t+ 5+ X+++() R* tv++ b+(++) DI++ D-(--) G- e h--(*) r++ y? --END GEEK CODE BLOCK-- To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: My wi(4) ate itself (or Fun with no memory).
On Mon, Dec 30, 2002 at 11:36:45AM -0800, Juli Mallett wrote: > Hey, > > I ran some stuff overnight which exhausted my system's memory fairly well, > and was also thrashing around on my network, and I woke up to find that my > wi(4) blew up more or less: > > wi0: watchdog timeout > wi0: timeout in wi_cmd 0x0002; event status 0x8000 > wi0: timeout in wi_cmd 0x; event status 0x8000 > wi0: wi_cmd: busy bit won't clear. > wi0: wi_cmd: busy bit won't clear. > wi0: init failed > wi0: wi_cmd: busy bit won't clear. > wi0: wi_cmd: busy bit won't clear. > wi0: wi_cmd: busy bit won't clear. > wi0: wi_cmd: busy bit won't clear. > wi0: wi_cmd: busy bit won't clear. > wi0: wi_cmd: busy bit won't clear. > wi0: wi_cmd: busy bit won't clear. > wi0: wi_cmd: busy bit won't clear. > wi0: wi_cmd: busy bit won't clear. > wi0: wi_cmd: busy bit won't clear. > wi0: wi_cmd: busy bit won't clear. > wi0: wi_cmd: busy bit won't clear. > wi0: wi_cmd: busy bit won't clear. > wi0: wi_cmd: busy bit won't clear. > wi0: wi_cmd: busy bit won't clear. > wi0: wi_cmd: busy bit won't clear. > wi0: wi_cmd: busy bit won't clear. > wi0: wi_cmd: busy bit won't clear. > wi0: wi_cmd: busy bit won't clear. > wi0: wi_cmd: busy bit won't clear. > wi0: wi_cmd: busy bit won't clear. > wi0: wi_cmd: busy bit won't clear. > wi0: failed to allocate 1594 bytes on NIC > wi0: tx buffer allocation failed > wi0: wi_cmd: busy bit won't clear. > wi0: failed to allocate 1594 bytes on NIC > wi0: mgmt. buffer allocation failed > Expensive timeout(9) function: 0xc02aefa0(0) 127.445894221 > wi0: timeout in wi_seek to 0/0; last status 4000 > wi0: timeout in wi_seek to 0/44; last status 4044 > wi0: wi_cmd: busy bit won't clear. > wi0: xmit failed > Expensive timeout(9) function: 0xc02cfde0(0xc1a08ccc) 7.384429976 > wi0: watchdog timeout > wi0: wi_cmd: busy bit won't clear. > wi0: wi_cmd: busy bit won't clear. > wi0: wi_cmd: busy bit won't clear. > wi0: wi_cmd: busy bit won't clear. > wi0: init failed > wi0: wi_cmd: busy bit won't clear. > wi0: wi_cmd: busy bit won't clear. > wi0: wi_cmd: busy bit won't clear. > wi0: wi_cmd: busy bit won't clear. > wi0: wi_cmd: busy bit won't clear. > wi0: wi_cmd: busy bit won't clear. > wi0: wi_cmd: busy bit won't clear. > wi0: wi_cmd: busy bit won't clear. > wi0: wi_cmd: busy bit won't clear. > wi0: wi_cmd: busy bit won't clear. > wi0: wi_cmd: busy bit won't clear. > wi0: wi_cmd: busy bit won't clear. > wi0: wi_cmd: busy bit won't clear. > wi0: wi_cmd: busy bit won't clear. > wi0: wi_cmd: busy bit won't clear. > wi0: wi_cmd: busy bit won't clear. > wi0: wi_cmd: busy bit won't clear. > wi0: wi_cmd: busy bit won't clear. > wi0: wi_cmd: busy bit won't clear. > wi0: wi_cmd: busy bit won't clear. > wi0: wi_cmd: busy bit won't clear. > wi0: wi_cmd: busy bit won't clear. > wi0: failed to allocate 1594 bytes on NIC > wi0: tx buffer allocation failed > wi0: wi_cmd: busy bit won't clear. > wi0: failed to allocate 1594 bytes on NIC > wi0: mgmt. buffer allocation failed > Expensive timeout(9) function: 0xc02aefa0(0) 135.098850348 > wi0: timeout in wi_seek to 0/0; last status 4000 > wi0: timeout in wi_seek to 0/44; last status 4044 > wi0: wi_cmd: busy bit won't clear. > wi0: xmit failed > > Was how it started, and then a lot more of the 'busy bit won't clear' > messages. I ejected the card after de-b0rking the rest of the system, and > was able to bring it back up fine, but thought maybe someone might have some > insight into how exactly my wi(4) blew up, and whether this is an acceptable > failure case :) > > Thanx, > juli. > -- > Juli Mallett <[EMAIL PROTECTED]> > AIM: BSDFlata IRC: juli@EFnet#flata > OpenDarwin, Mono, FreeBSD Developer. > ircd-hybrid Developer, EFnet addict. > FreeBSD on MIPS-Anything on FreeBSD. > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-current" in the body of the message > > I get those messages when running dstumbler and then trying to do other stuff with the device. The bad thing is, that the chip is integrated in my notebook so i can't simply take it out and back in again :-) Is there any other way to reinitialize the card? - Christian -- http://www.unixpages.org[EMAIL PROTECTED] GPG Pub-Key: www.unixpages.org/cbrueffer.asc GPG Fingerprint: A5C8 2099 19FF AACA F41B B29B 6C76 178C A0ED 982D GPG Key ID : 0xA0ED982D msg49447/pgp0.pgp Description: PGP signature
mount_portalfs broken in 5.0-RC2
Hello, as announced on freebsd-hackers a few days ago, I ported the rfilter/wfilter features of NetBSD's mount_portal to 4.7-p2. Because the port was very trivial and rfilter/wfilter worked well on 4.7-p2, I tried to merge the code in 5.0-RC2 mount_portalfs and discovered, that mount_portalfs did not work. First I thought this is a problem with the rfilter/wfilter code, but also the original mount_portalfs has this problem. Description: my portal.conf: tcp/ tcp tcp/ tcplisten/ tcplisten tcplisten/ fs/file fs/ 1.) After mounting the portalfs, # cat /p/tcp/www.jawa.at/21 220 ftp.jawa.at FTP server (ftpd) ready. ^C portalfs hangs, and cat did not return on ^C or ^Z 2.) After mounting the portalfs, # cat /p/tcp or # cat /p/telnet or # cat /p/http portalfs hangs instead of expected "cat: /p/telnet: No such file or directory" Impact: - umount /p does not work - Further access to /p is not possible (e.x. ls) - FreeBSD could not unmount all file systems on reboot, so fsck has to run on next boot. Regards, /\/\ichael Ranner [EMAIL PROTECTED] - [EMAIL PROTECTED] - [EMAIL PROTECTED] -- JAWA Management Software GmbH - http://www.jawa.at/ Liebenauer Hauptstrasse 2oo - A-8041 Graz Tel +43 316 403274 21 - Fax +43 316 403274 10 -- Mariazell Online - http://www.mariazell.at/ -- -BEGIN GEEK CODE BLOCK- GIT/CS/AT dx(-) s+:(++:) a- C++ UBLVS$ P++>+++$ L-(+)$ E--- W+++$ N+(++) o-- K- w--()$ O-(--) M@ V-(--) PS+>++ PE(-) Y+ PGP(-) t+ 5+ X+++() R* tv++ b+(++) DI++ D-(--) G- e h--(*) r++ y? --END GEEK CODE BLOCK-- To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: My wi(4) ate itself (or Fun with no memory).
In message: <[EMAIL PROTECTED]> Juli Mallett <[EMAIL PROTECTED]> writes: : I ran some stuff overnight which exhausted my system's memory fairly well, : and was also thrashing around on my network, and I woke up to find that my : wi(4) blew up more or less: : : wi0: watchdog timeout : wi0: timeout in wi_cmd 0x0002; event status 0x8000 : wi0: timeout in wi_cmd 0x; event status 0x8000 : wi0: wi_cmd: busy bit won't clear. The firmware on your card hung hard. The wi driver doesn't deal with that at all well (although one could rightly argue it should). Why the firmware hung hard, I cannot say. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Trouble building X on fresh 5.0-RC2 install?
It runs fine for me off of a fresh RC2 install. I run KDE 3.0.5 on top of it. Tom Veldhouse - Original Message - From: "Peter Kostouros" <[EMAIL PROTECTED]> To: "walt" <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]> Sent: Monday, December 30, 2002 3:20 PM Subject: Re: Trouble building X on fresh 5.0-RC2 install? > Hi > > It has been mentioned a few times, though not specifically for RC2. > Check the archives for > subjects "X server - undefined symbols" and "XFree 4.2.1 doesn't work > with last CURRENT". > > > walt wrote: > > > I've installed RC2 on my new ASUS A7V8X/AthlonXP and the > > whole thing went very well except for building XFree. > > > > X does compile with no complaints but when I attempt to > > run it I get unresolved symbol errors and then a coredump. > > > > I'm not asking for a fix here, really, so I won't bother > > you with debugging details. I'm just curious if > > anyone else has had problems building X recently. > > > > I'm a bit reluctant to try re-compiling it on my old > > "stable" -CURRENT box because it's working so well ;) > > > > > > To Unsubscribe: send mail to [EMAIL PROTECTED] > > with "unsubscribe freebsd-current" in the body of the message > > > > > > > -- > > Regards > > Peter > > As always the organisation disavows knowledge of this email > > > > 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: Trouble building X on fresh 5.0-RC2 install?
Hi It has been mentioned a few times, though not specifically for RC2. Check the archives for subjects "X server - undefined symbols" and "XFree 4.2.1 doesn't work with last CURRENT". walt wrote: I've installed RC2 on my new ASUS A7V8X/AthlonXP and the whole thing went very well except for building XFree. X does compile with no complaints but when I attempt to run it I get unresolved symbol errors and then a coredump. I'm not asking for a fix here, really, so I won't bother you with debugging details. I'm just curious if anyone else has had problems building X recently. I'm a bit reluctant to try re-compiling it on my old "stable" -CURRENT box because it's working so well ;) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message -- Regards Peter As always the organisation disavows knowledge of this email To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
sparc64 tinderbox failure
Tinderbox FAQ: http://people.FreeBSD.org/~mike/tinderbox.html -- >>> Rebuilding the temporary build tree -- >>> stage 1: bootstrap tools -- >>> stage 2: cleaning up the object tree -- >>> stage 2: rebuilding the object tree -- >>> stage 2: build tools -- >>> stage 3: cross tools -- >>> stage 4: populating >/tinderbox/sparc64/obj/tinderbox/sparc64/src/sparc64/usr/include -- >>> stage 4: building libraries -- >>> stage 4: make dependencies -- >>> stage 4: building everything.. -- ===> bin/df cc1: warnings being treated as errors /tinderbox/sparc64/src/bin/df/df.c: In function `prtstat': /tinderbox/sparc64/src/bin/df/df.c:395: warning: passing arg 1 of `getbsize' from incompatible pointer type /tinderbox/sparc64/src/bin/df/df.c: In function `update_maxwidths': /tinderbox/sparc64/src/bin/df/df.c:448: warning: passing arg 1 of `getbsize' from incompatible pointer type *** Error code 1 Stop in /tinderbox/sparc64/src/bin/df. *** Error code 1 Stop in /tinderbox/sparc64/src/bin. *** Error code 1 Stop in /tinderbox/sparc64/src. *** Error code 1 Stop in /tinderbox/sparc64/src. *** Error code 1 Stop in /tinderbox/sparc64/src. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: UMASS USB bug? (getting the Sony disk-on-key device working)
On 19-Dec-2002 Matthew Dillon wrote: > This is a real mess but I finally got it to work. (Note > to John: both quirk entries are absolutely necessary, > everything stalls and dies without them). You might need to lie to umass and tell if to use the UFI or ATAPI protocols instead of SCSI. USB SCSI devices are supposed to support 6 byte commands. Alternatively, we could do the 6 to 10 translation for SCSI devices as well as UFI and ATAPI devices. -- John Baldwin <[EMAIL PROTECTED]> <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
My wi(4) ate itself (or Fun with no memory).
Hey, I ran some stuff overnight which exhausted my system's memory fairly well, and was also thrashing around on my network, and I woke up to find that my wi(4) blew up more or less: wi0: watchdog timeout wi0: timeout in wi_cmd 0x0002; event status 0x8000 wi0: timeout in wi_cmd 0x; event status 0x8000 wi0: wi_cmd: busy bit won't clear. wi0: wi_cmd: busy bit won't clear. wi0: init failed wi0: wi_cmd: busy bit won't clear. wi0: wi_cmd: busy bit won't clear. wi0: wi_cmd: busy bit won't clear. wi0: wi_cmd: busy bit won't clear. wi0: wi_cmd: busy bit won't clear. wi0: wi_cmd: busy bit won't clear. wi0: wi_cmd: busy bit won't clear. wi0: wi_cmd: busy bit won't clear. wi0: wi_cmd: busy bit won't clear. wi0: wi_cmd: busy bit won't clear. wi0: wi_cmd: busy bit won't clear. wi0: wi_cmd: busy bit won't clear. wi0: wi_cmd: busy bit won't clear. wi0: wi_cmd: busy bit won't clear. wi0: wi_cmd: busy bit won't clear. wi0: wi_cmd: busy bit won't clear. wi0: wi_cmd: busy bit won't clear. wi0: wi_cmd: busy bit won't clear. wi0: wi_cmd: busy bit won't clear. wi0: wi_cmd: busy bit won't clear. wi0: wi_cmd: busy bit won't clear. wi0: wi_cmd: busy bit won't clear. wi0: failed to allocate 1594 bytes on NIC wi0: tx buffer allocation failed wi0: wi_cmd: busy bit won't clear. wi0: failed to allocate 1594 bytes on NIC wi0: mgmt. buffer allocation failed Expensive timeout(9) function: 0xc02aefa0(0) 127.445894221 wi0: timeout in wi_seek to 0/0; last status 4000 wi0: timeout in wi_seek to 0/44; last status 4044 wi0: wi_cmd: busy bit won't clear. wi0: xmit failed Expensive timeout(9) function: 0xc02cfde0(0xc1a08ccc) 7.384429976 wi0: watchdog timeout wi0: wi_cmd: busy bit won't clear. wi0: wi_cmd: busy bit won't clear. wi0: wi_cmd: busy bit won't clear. wi0: wi_cmd: busy bit won't clear. wi0: init failed wi0: wi_cmd: busy bit won't clear. wi0: wi_cmd: busy bit won't clear. wi0: wi_cmd: busy bit won't clear. wi0: wi_cmd: busy bit won't clear. wi0: wi_cmd: busy bit won't clear. wi0: wi_cmd: busy bit won't clear. wi0: wi_cmd: busy bit won't clear. wi0: wi_cmd: busy bit won't clear. wi0: wi_cmd: busy bit won't clear. wi0: wi_cmd: busy bit won't clear. wi0: wi_cmd: busy bit won't clear. wi0: wi_cmd: busy bit won't clear. wi0: wi_cmd: busy bit won't clear. wi0: wi_cmd: busy bit won't clear. wi0: wi_cmd: busy bit won't clear. wi0: wi_cmd: busy bit won't clear. wi0: wi_cmd: busy bit won't clear. wi0: wi_cmd: busy bit won't clear. wi0: wi_cmd: busy bit won't clear. wi0: wi_cmd: busy bit won't clear. wi0: wi_cmd: busy bit won't clear. wi0: wi_cmd: busy bit won't clear. wi0: failed to allocate 1594 bytes on NIC wi0: tx buffer allocation failed wi0: wi_cmd: busy bit won't clear. wi0: failed to allocate 1594 bytes on NIC wi0: mgmt. buffer allocation failed Expensive timeout(9) function: 0xc02aefa0(0) 135.098850348 wi0: timeout in wi_seek to 0/0; last status 4000 wi0: timeout in wi_seek to 0/44; last status 4044 wi0: wi_cmd: busy bit won't clear. wi0: xmit failed Was how it started, and then a lot more of the 'busy bit won't clear' messages. I ejected the card after de-b0rking the rest of the system, and was able to bring it back up fine, but thought maybe someone might have some insight into how exactly my wi(4) blew up, and whether this is an acceptable failure case :) Thanx, juli. -- Juli Mallett <[EMAIL PROTECTED]> AIM: BSDFlata IRC: juli@EFnet#flata OpenDarwin, Mono, FreeBSD Developer. ircd-hybrid Developer, EFnet addict. FreeBSD on MIPS-Anything on FreeBSD. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
powerpc tinderbox failure
-- >>> Rebuilding the temporary build tree -- >>> stage 1: bootstrap tools -- >>> stage 2: cleaning up the object tree -- >>> stage 2: rebuilding the object tree -- >>> stage 2: build tools -- >>> stage 3: cross tools -- >>> stage 4: populating /home/tinderbox/ppc/obj/home/tinderbox/ppc/src/ppc/usr/include -- >>> stage 4: building libraries -- >>> stage 4: make dependencies -- >>> stage 4: building everything.. -- ===> bin/df cc1: warnings being treated as errors /home/tinderbox/ppc/src/bin/df/df.c: In function `prtstat': /home/tinderbox/ppc/src/bin/df/df.c:395: warning: passing arg 1 of `getbsize' from incompatible pointer type /home/tinderbox/ppc/src/bin/df/df.c: In function `update_maxwidths': /home/tinderbox/ppc/src/bin/df/df.c:448: warning: passing arg 1 of `getbsize' from incompatible pointer type *** Error code 1 Stop in /home/tinderbox/ppc/src/bin/df. *** Error code 1 Stop in /home/tinderbox/ppc/src/bin. *** Error code 1 Stop in /home/tinderbox/ppc/src. *** Error code 1 Stop in /home/tinderbox/ppc/src. *** Error code 1 Stop in /home/tinderbox/ppc/src. _ BootBox.Net - Your Home on the Internet http://www.bootbox.net Get an @bootbox.net webmail account - http://webmail.bootbox.net Get Dialup Internet Access for only $8.95/mo http://isp.bootbox.net Host Your Website For Free- http://webhosting.bootbox.net Put Your E-Commerce Business Online Virtually Free - http://bcommerce.bootbox.net _ Select your own custom email address for FREE! Get [EMAIL PROTECTED] w/No Ads, 6MB, POP & more! http://www.everyone.net/selectmail?campaign=tag To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
rc.conf ifconfig lines fail
Ever since RC2 I have had to manually execute the following two lines from my rc.conf, because they are not set at boot. ifconfig_fxp0="DHCP" ifconfig_wi0="inet up ssid my_ap mediaopt hostap" Have I missed something? Thanks, Pete... To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
ia64 tinderbox failure
-- >>> Rebuilding the temporary build tree -- >>> stage 1: bootstrap tools -- >>> stage 2: cleaning up the object tree -- >>> stage 2: rebuilding the object tree -- >>> stage 2: build tools -- >>> stage 3: cross tools -- >>> stage 4: populating >/home/tinderbox/ia64/obj/home/tinderbox/ia64/src/ia64/usr/include -- >>> stage 4: building libraries -- >>> stage 4: make dependencies -- >>> stage 4: building everything.. -- ===> bin/df cc1: warnings being treated as errors /home/tinderbox/ia64/src/bin/df/df.c: In function `prtstat': /home/tinderbox/ia64/src/bin/df/df.c:395: warning: passing arg 1 of `getbsize' from incompatible pointer type /home/tinderbox/ia64/src/bin/df/df.c: In function `update_maxwidths': /home/tinderbox/ia64/src/bin/df/df.c:448: warning: passing arg 1 of `getbsize' from incompatible pointer type *** Error code 1 Stop in /home/tinderbox/ia64/src/bin/df. *** Error code 1 Stop in /home/tinderbox/ia64/src/bin. *** Error code 1 Stop in /home/tinderbox/ia64/src. *** Error code 1 Stop in /home/tinderbox/ia64/src. *** Error code 1 Stop in /home/tinderbox/ia64/src. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
I'm being over digestified.
Anyone else get more digest than normal. In the last week or so I now get 5 copies of each digest and have done nothing at all on my side with any subscriptions. Bill -- Bill Vermillion - bv @ wjv . com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: FEC on 5.x
Hello, [taken from -hackers] > Can you try use tcpdump to comparte something that works with the code > that doesn't. tcpdump -i fec0 shows the following: if I ping our-router I see the packages going out, but nothing coming back. The switch shows 0 input packets. I pinged the machine, then it paniced (please, somebody tell me, what should I do if I don't have a kern.dumpdev sysctl and ddb> panic can't write a crashdump -> http://marc.theaimsgroup.com/?l=freebsd-hackers&m=104107316521812&w=2) BTW, the switch shows output packets, but tcpdump has nothing incoming... This happened last week. Today I tried again and got the following results: tcpdump -i fec0 shows outgoing pings, but there are no incoming packets. tcpdump -i fxp0 & tcpdump -i fxp1 shows the incoming "noise" (bridge STP negotiations, etc), but do not show any traces of the outgoing ICMP packets. So it seems the fec0 interface has no connection with the fxp[0-1] ones. How could I do more testing? Would a serial console to the machine help? It's for testing purposes... Finally, here is what I did: ifconfig fxp0 up ifconfig fxp1 up ngctl mkpeer fec dummy fec ngctl msg fec0: add_iface '"fxp0"' ngctl msg fec0: add_iface '"fxp1"' ngctl msg fec0: set_mode_inet ifconfig fec0 a.b.c.d netmask 255.255.255.252 up The interface becomes up (according to the switch and FreeBSD) and shows the above effects. --[ Free Software ISOs - http://www.fsn.hu/?f=download ]-- Attila Nagy e-mail: [EMAIL PROTECTED] Free Software Network (FSN.HU)phone @work: +361 210 1415 (194) cell.: +3630 306 6758 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
sparc64 tinderbox failure
Tinderbox FAQ: http://people.FreeBSD.org/~mike/tinderbox.html -- >>> Rebuilding the temporary build tree -- >>> stage 1: bootstrap tools -- >>> stage 2: cleaning up the object tree -- ===> usr.sbin/fwcontrol cd: can't cd to /tinderbox/sparc64/src/usr.sbin/fwcontrol *** Error code 2 Stop in /tinderbox/sparc64/src/usr.sbin. *** Error code 1 Stop in /tinderbox/sparc64/src. *** Error code 1 Stop in /tinderbox/sparc64/src. *** Error code 1 Stop in /tinderbox/sparc64/src. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: missed disk nodes
In message <[EMAIL PROTECTED]>, Andrey Koklin writes: >Hi folks, > >Silly question, perhaps, but I wasn't able to figure out source of the >problem myself... > >I used rarely magneto-optical disks to transfer data to/from Windows >machine. For compatibility, disks used HDD FAT16 format. >About a month ago the disks began to refuse to mount under -current: Can you please: dd if=/dev/da2 bs=64k | uuencode - foo | mail [EMAIL PROTECTED] I have not had an example of a non-512 byte disk with MBR on it until now. Poul-Henning > ># cat /var/run/dmesg.boot |grep '^da2' >da2 at ahc0 bus 0 target 6 lun 0 >da2: Removable Optical SCSI-2 device >da2: 10.000MB/s transfers (10.000MHz, offset 10) >da2: 606MB (310352 2048 byte sectors: 64H 32S/T 151C) > ># fdisk /dev/da2 >*** Working on device /dev/da2 *** >parameters extracted from in-core disklabel are: >cylinders=151 heads=64 sectors/track=32 (2048 blks/cyl) > >parameters to be used for BIOS calculations are: >cylinders=151 heads=64 sectors/track=32 (2048 blks/cyl) > >Media sector size is 2048 >Warning: BIOS sector numbering starts with sector 1 >Information from DOS bootblock is: >The data for partition 1 is: >sysid 6 (0x06),(Primary 'big' DOS (>= 32MB)) >start 32, size 309216 (603 Meg), flag 80 (active) >beg: cyl 0/ head 1/ sector 1; >end: cyl 150/ head 63/ sector 32 >The data for partition 2 is: > >The data for partition 3 is: > >The data for partition 4 is: > > ># mount_msdosfs /dev/da2s1c /mnt >mount_msdosfs: /dev/da2s1c: No such file or directory > >Indeed, there is only /dev/da2 node now. > >But how can I tell the devfs system to create needed nodes? > > >-- >Regards, >Andrey > > > > >To Unsubscribe: send mail to [EMAIL PROTECTED] >with "unsubscribe freebsd-current" in the body of the message > -- 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: ia64 tinderbox failure
> Agreed. It really should be an int * like it used to be. But it's > up to Mark Murray to fix it since it was his commit that changed it > to a size_t in the first place. I'm not religiously attached to this. If you want to change it before I get to it, go ahead. M -- Mark Murray iumop ap!sdn w,I idlaH To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
sparc64 tinderbox failure
Tinderbox FAQ: http://people.FreeBSD.org/~mike/tinderbox.html -- >>> Rebuilding the temporary build tree -- >>> stage 1: bootstrap tools -- >>> stage 2: cleaning up the object tree -- >>> stage 2: rebuilding the object tree -- >>> stage 2: build tools -- >>> stage 3: cross tools -- >>> stage 4: populating >/tinderbox/sparc64/obj/tinderbox/sparc64/src/sparc64/usr/include -- >>> stage 4: building libraries -- >>> stage 4: make dependencies -- >>> stage 4: building everything.. -- ===> sbin/swapon cc1: warnings being treated as errors /tinderbox/sparc64/src/sbin/swapon/swapon.c: In function `swaplist': /tinderbox/sparc64/src/sbin/swapon/swapon.c:246: warning: field width is not type int (arg 3) /tinderbox/sparc64/src/sbin/swapon/swapon.c:246: warning: field width is not type int (arg 5) /tinderbox/sparc64/src/sbin/swapon/swapon.c:265: warning: field width is not type int (arg 3) /tinderbox/sparc64/src/sbin/swapon/swapon.c:265: warning: field width is not type int (arg 5) /tinderbox/sparc64/src/sbin/swapon/swapon.c:274: warning: field width is not type int (arg 2) /tinderbox/sparc64/src/sbin/swapon/swapon.c:274: warning: field width is not type int (arg 4) *** Error code 1 Stop in /tinderbox/sparc64/src/sbin/swapon. *** Error code 1 Stop in /tinderbox/sparc64/src/sbin. *** Error code 1 Stop in /tinderbox/sparc64/src. *** Error code 1 Stop in /tinderbox/sparc64/src. *** Error code 1 Stop in /tinderbox/sparc64/src. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: PAWS ack-on-ack loop avoided
On Mon, Dec 23, 2002 at 10:55:05 -0800, Matthew Dillon wrote: > > That's very odd. I see them on my development box too which is just > talking FreeBSD<->FreeBSD. We should not be seeing them at all. I found that big source of them is Windows machines when Selective acknowledgement is turned on on their side. -- Andrey A. Chernov http://ache.pp.ru/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
missed disk nodes
Hi folks, Silly question, perhaps, but I wasn't able to figure out source of the problem myself... I used rarely magneto-optical disks to transfer data to/from Windows machine. For compatibility, disks used HDD FAT16 format. About a month ago the disks began to refuse to mount under -current: # cat /var/run/dmesg.boot |grep '^da2' da2 at ahc0 bus 0 target 6 lun 0 da2: Removable Optical SCSI-2 device da2: 10.000MB/s transfers (10.000MHz, offset 10) da2: 606MB (310352 2048 byte sectors: 64H 32S/T 151C) # fdisk /dev/da2 *** Working on device /dev/da2 *** parameters extracted from in-core disklabel are: cylinders=151 heads=64 sectors/track=32 (2048 blks/cyl) parameters to be used for BIOS calculations are: cylinders=151 heads=64 sectors/track=32 (2048 blks/cyl) Media sector size is 2048 Warning: BIOS sector numbering starts with sector 1 Information from DOS bootblock is: The data for partition 1 is: sysid 6 (0x06),(Primary 'big' DOS (>= 32MB)) start 32, size 309216 (603 Meg), flag 80 (active) beg: cyl 0/ head 1/ sector 1; end: cyl 150/ head 63/ sector 32 The data for partition 2 is: The data for partition 3 is: The data for partition 4 is: # mount_msdosfs /dev/da2s1c /mnt mount_msdosfs: /dev/da2s1c: No such file or directory Indeed, there is only /dev/da2 node now. But how can I tell the devfs system to create needed nodes? -- Regards, Andrey To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: missing support for std::wstring breaks stuff on -CURRENT
On Sun, Dec 29, 2002 at 08:24:23PM +0100, Simon 'corecode' Schubert wrote: > would please somebody look into this case and explain why wchar_t > support wasn't enabled? Because the GCC developers disabled it for GCC 3.2.1 > tim robins already provided a patch that will make stuff working. Please dig into why the above occured, and if it still seems reasonable to commit Tim's patch, I will. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
