workstation DNS issue
My BSD workstation can't resolve names fast. It used to work immediately but all of a sudden it slowed down. The Windows machines are able to resolve names fast. >From the looks of "dig", it's not reading in the nameservers from resolv.conf. Help please. I have FreeBSD 6.0-RELEASE. %less /etc/resolv.conf #search 192.168.1.1 nameserver 204.127.202.19 nameserver 216.148.227.79 nameserver 68.87.68.162 # dig ; <<>> DiG 9.3.1 <<>> ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 48493 ;; flags: qr rd ra; QUERY: 1, ANSWER: 13, AUTHORITY: 0, ADDITIONAL: 13 ;; QUESTION SECTION: ;. IN NS ;; ANSWER SECTION: . 447965 IN NS a.root-servers.net. . 447965 IN NS h.root-servers.net. . 447965 IN NS c.root-servers.net. . 447965 IN NS g.root-servers.net. . 447965 IN NS f.root-servers.net. . 447965 IN NS b.root-servers.net. . 447965 IN NS j.root-servers.net. . 447965 IN NS k.root-servers.net. . 447965 IN NS l.root-servers.net. . 447965 IN NS m.root-servers.net. . 447965 IN NS i.root-servers.net. . 447965 IN NS e.root-servers.net. . 447965 IN NS d.root-servers.net. ;; ADDITIONAL SECTION: h.root-servers.net. 569691 IN A 128.63.2.53 c.root-servers.net. 569691 IN A 192.33.4.12 g.root-servers.net. 569691 IN A 192.112.36.4 f.root-servers.net. 569691 IN A 192.5.5.241 b.root-servers.net. 569691 IN A 192.228.79.201 j.root-servers.net. 569691 IN A 192.58.128.30 k.root-servers.net. 569691 IN A 193.0.14.129 l.root-servers.net. 569691 IN A 198.32.64.12 m.root-servers.net. 569691 IN A 202.12.27.33 i.root-servers.net. 569691 IN A 192.36.148.17 e.root-servers.net. 569691 IN A 192.203.230.10 d.root-servers.net. 569691 IN A 128.8.10.90 a.root-servers.net. 569691 IN A 198.41.0.4 ;; Query time: 12 msec ;; SERVER: 68.87.68.162#53(68.87.68.162) ;; WHEN: Tue Apr 25 20:21:38 2006 ;; MSG SIZE rcvd: 436 -- Ashok Shrestha ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: workstation DNS issue
Hi, Ashok Shrestha wrote: %less /etc/resolv.conf #search 192.168.1.1 nameserver 204.127.202.19 nameserver 216.148.227.79 nameserver 68.87.68.162 before going deeper. Did you try to change the sequence of these entries? Try it and compare then the results. Erich ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: workstation DNS issue
2006/4/26, Ashok Shrestha <[EMAIL PROTECTED]>: > #search 192.168.1.1 i know it'commented out, btw: 'search' need a domain name, not an ip address > nameserver 204.127.202.19 > nameserver 216.148.227.79 > nameserver 68.87.68.162 are you sure these are public dns? are you allowed to use them from your network? try: dig @204.127.202.19 www.freebsd.org dig @216.148.227.79 www.freebsd.org dig @68.87.68.162 www.freebsd.org What are the answers? -- Cris, member of G.U.F.I Italian FreeBSD User Group http://www.gufi.org/ ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Keyboard Boot Disable
On Tue, Apr 25, 2006 at 06:27:53PM -0400 I heard the voice of Lucas Holt, and lo! it spake thus: > > I worked with someone once that said they blew out the ps/2 port on > the motherboard. I've seen this happen several times. Some boards were later revived by judicious use of a soldering iron, but not all. These days, I'd think USB keyboards would be easier than KVM switches. -- Matthew Fuller (MF4839) | [EMAIL PROTECTED] Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ On the Internet, nobody can hear you scream. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Can kldload trigger pci bus rescan?
Hi guys: I tried to use kldload to load our HBA driver. But the driver's pci probe function can not find the HBA card! Does it mean that kldload can not trigger pci bus rescan? If so, what should I do for triggering pci bus rescan after loading our pci driver? Thank you for your help! Hong ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Can kldload trigger pci bus rescan?
On Wednesday 26 April 2006 17:17, [EMAIL PROTECTED] wrote: > I tried to use kldload to load our HBA driver. But the driver's pci probe > function can not find the HBA card! Does it mean that kldload can not > trigger pci bus rescan? If so, what should I do for triggering pci bus > rescan after loading our pci driver? It will reprobe.. Well, all of the probe functions in the kernel will be called again. -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C pgpKZKi45FocR.pgp Description: PGP signature
Re: [ANN] unionfs patchset-11 release
Kris Kennaway wrote: > I still get a panic immediately upon use: OKey. Maybe we fixed your panic. Please try attached file as /usr/src/sys/fs/unionfs/union_vnops.c :) -- Daichi GOTO, http://people.freebsd.org/~daichi ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: [ANN] unionfs patchset-11 release
Robert Watson wrote: If someone knows the details of vnode's lock status via VOP_GETWRITEMOUNT, Please teach us (daichi, ozawa). We want to know the details. Basically, file systems supporting full file system snapshots (UFS) Oh thanks rwatson! It is very useful. Thank you very much :) -- Daichi GOTO, http://people.freebsd.org/~daichi ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: [ANN] unionfs patchset-11 release
Munehiro Matsuda wrote: How about this? Great! I just updated site. Thanks Matsuda-san :) http://people.freebsd.org/~daichi/unionfs/ -- Daichi GOTO, http://people.freebsd.org/~daichi ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: [ANN] unionfs patchset-11 release
Fabian Keil wrote: Looks like the attachment was filtered. I got a different panic on FreeBSD TP51.local 6.1-RC FreeBSD 6.1-RC #22: Wed Apr 26 13:25:57 CEST 2006 after mounting an empty directory above /usr/src, applying a patch and using find's -type f option shortly afterwards to show the files in the directory on top: M... We tried as follow, but we could not get the same error :( It looks very fine. # cd /usr/ # mkdir hoge # mount_unionfs -c transparent -o noatime /usr/hoge /usr/src # cd src # find . -type f &; find . -type f &; find . -type f & # cd /usr/ # umount /usr/src # rm -r hoge # mkdir hoge # mount_unionfs -c transparent /usr/hoge /usr/src # cd src # find . -type f &; find . -type f &; find . -type f & What do you make of it? -- Daichi GOTO, http://people.freebsd.org/~daichi ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: [ANN] unionfs patchset-11 release
Daichi GOTO <[EMAIL PROTECTED]> wrote: > Fabian Keil wrote: > > Looks like the attachment was filtered. > > > > I got a different panic on > > FreeBSD TP51.local 6.1-RC FreeBSD 6.1-RC #22: Wed Apr 26 13:25:57 CEST 2006 > > after mounting an empty directory above /usr/src, > > applying a patch and using find's -type f option shortly afterwards > > to show the files in the directory on top: > > M... > > We tried as follow, but we could not get the same error :( > It looks very fine. > > # cd /usr/ > # mkdir hoge > # mount_unionfs -c transparent -o noatime /usr/hoge /usr/src > # cd src > # find . -type f &; find . -type f &; find . -type f & > # cd /usr/ > # umount /usr/src > # rm -r hoge > # mkdir hoge > # mount_unionfs -c transparent /usr/hoge /usr/src > # cd src > # find . -type f &; find . -type f &; find . -type f & > > What do you make of it? I didn't give you enough information, sorry. What I'm doing is: [EMAIL PROTECTED] ~ $mkdir /tmp/unionfs-src/ [EMAIL PROTECTED] ~ $mount_unionfs /tmp/unionfs-src /usr/src [EMAIL PROTECTED] ~ $cd /usr/src [EMAIL PROTECTED] /usr/src $patch -p1 < ~/test/combi.patch [EMAIL PROTECTED] /usr/src $find /tmp/unionfs-src/ -type f [Panic] ~/test/combi.patch changes about twenty files. I'm not sure if it's important, but /usr was mounted readonly and /tmp is a different file system. My kernel has options WITNESS enabled. The last step doesn't seem to be the only way to get a problem, I tried the first four steps again and umount /usr/src resulted in a reboot. I was running Xorg and didn't get a panic, but I'll try again without Xorg, to see if it's the same problem. Fabian -- http://www.fabiankeil.de/ signature.asc Description: PGP signature
Re: [ANN] unionfs patchset-11 release
Fabian Keil <[EMAIL PROTECTED]> wrote:
> Daichi GOTO <[EMAIL PROTECTED]> wrote:
>
> > Fabian Keil wrote:
> > > I got a different panic on
> > > FreeBSD TP51.local 6.1-RC FreeBSD 6.1-RC #22: Wed Apr 26 13:25:57 CEST
> > > 2006
> > > after mounting an empty directory above /usr/src,
> > > applying a patch and using find's -type f option shortly afterwards
> > > to show the files in the directory on top:
> > We tried as follow, but we could not get the same error :(
> > It looks very fine.
> I didn't give you enough information, sorry.
>
> What I'm doing is:
>
> [EMAIL PROTECTED] ~ $mkdir /tmp/unionfs-src/
> [EMAIL PROTECTED] ~ $mount_unionfs /tmp/unionfs-src /usr/src
> [EMAIL PROTECTED] ~ $cd /usr/src
> [EMAIL PROTECTED] /usr/src $patch -p1 < ~/test/combi.patch
> [EMAIL PROTECTED] /usr/src $find /tmp/unionfs-src/ -type f
> [Panic]
>
> ~/test/combi.patch changes about twenty files.
>
> I'm not sure if it's important, but /usr was mounted
> readonly and /tmp is a different file system.
>
> My kernel has options WITNESS enabled.
>
> The last step doesn't seem to be the only way to
> get a problem, I tried the first four steps again
> and umount /usr/src resulted in a reboot.
>
> I was running Xorg and didn't get a panic, but I'll
> try again without Xorg, to see if it's the same problem.
OK, I guess it's the same problem:
panic: initiate_write_filepage: dir inum 0 != new 8482
KDB: enter: panic
Locked vnodes
0xc359ddd0: tag syncer, type VNON
usecount 1, writecount 0, refcount 2 mountedhere 0
flags ()
lock type syncer: EXCL (count 1) by thread 0xc334ec00 (pid 41)
0xc393a880: tag ufs, type VDIR
usecount 1, writecount 0, refcount 3 mountedhere 0
flags ()
v_object 0xc3746e70 ref 0 pages 0
lock type ufs: EXCL (count 1) by thread 0xc334ec00 (pid 41)
ino 8469, on dev ad0s3e
exclusive sleep mutex Softdep Lock r = 0 (0xc07839c0) locked @
/usr/src/sys/ufs/ffs/ffs_softdep.c:3730
exclusive sleep mutex Giant r = 0 (0xc072f640) locked @
/usr/src/sys/kern/vfs_subr.c:1608
Locked vnodes
0xc359ddd0: tag syncer, type VNON
usecount 1, writecount 0, refcount 2 mountedhere 0
flags ()
lock type syncer: EXCL (count 1) by thread 0xc334ec00 (pid 41)
0xc393a880: tag ufs, type VDIR
usecount 1, writecount 0, refcount 3 mountedhere 0
flags ()
v_object 0xc3746e70 ref 0 pages 0
lock type ufs: EXCL (count 1) by thread 0xc334ec00 (pid 41)
ino 8469, on dev ad0s3e
panic: from debugger
Uptime: 2m14s
Dumping 511 MB (2 chunks)
chunk 0: 1MB (159 pages) ... ok
chunk 1: 511MB (130656 pages) 495 479 463 447 431 415 399 383 367 351 335 319
303 287 271 255 239 223 207 191 175 159 143 127 111 95 79 63 47 31 15
#0 doadump () at pcpu.h:165
165 pcpu.h: No such file or directory.
in pcpu.h
(kgdb) where
#0 doadump () at pcpu.h:165
#1 0xc054a865 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:402
#2 0xc054ab27 in panic (fmt=0xc06c9423 "from debugger") at
/usr/src/sys/kern/kern_shutdown.c:558
#3 0xc047f523 in db_panic (addr=-1068086451, have_addr=0, count=-1,
modif=0xd564b8d8 "") at /usr/src/sys/ddb/db_command.c:438
#4 0xc047f49c in db_command (last_cmdp=0xc072b3e4, cmd_table=0x0,
aux_cmd_tablep=0xc06f28c4, aux_cmd_tablep_end=0xc06f28c8)
at /usr/src/sys/ddb/db_command.c:350
#5 0xc047f58d in db_command_loop () at /usr/src/sys/ddb/db_command.c:458
#6 0xc048143d in db_trap (type=3, code=0) at /usr/src/sys/ddb/db_main.c:221
#7 0xc0564dd7 in kdb_trap (type=0, code=0, tf=0xd564ba24) at
/usr/src/sys/kern/subr_kdb.c:473
#8 0xc069e4d2 in trap (frame=
{tf_fs = -1066532856, tf_es = 40, tf_ds = -714866648, tf_edi = 1, tf_esi
= -1066511478, tf_ebp = -714818964, tf_isp = -714818992, tf_ebx = -714818908,
tf_edx = 0, tf_ecx = -1056878592, tf_eax = 18, tf_trapno = 3, tf_err = 0,
tf_eip = -1068086451, tf_cs = 32, tf_eflags = 642, tf_esp = -1066558175, tf_ss
= -1066564882}) at /usr/src/sys/i386/i386/trap.c:593
#9 0xc068feda in calltrap () at /usr/src/sys/i386/i386/exception.s:139
#10 0xc0564b4d in kdb_enter (msg=0x12 ) at
cpufunc.h:60
#11 0xc054aabf in panic (fmt=0xc06e538a "%s: dir inum %d != new %d") at
/usr/src/sys/kern/kern_shutdown.c:542
#12 0xc0634021 in initiate_write_filepage (pagedep=0xc354bc00, bp=0xcd838268)
at /usr/src/sys/ufs/ffs/ffs_softdep.c:3834
#13 0xc0633d1c in softdep_disk_io_initiation (bp=0xcd838268) at
/usr/src/sys/ufs/ffs/ffs_softdep.c:3740
#14 0xc063c8c4 in ffs_geom_strategy (bo=0xc358aa50, bp=0xcd838268) at buf.h:422
#15 0xc0648db7 in ufs_strategy (ap=0x12) at
/usr/src/sys/ufs/ufs/ufs_vnops.c:1942
#16 0xc06b47c8 in VOP_STRATEGY_APV (vop=0xc0719380, a=0xd564bb68) at
vnode_if.c:1796
#17 0xc059965c in bufstrategy (bo=0xc393a940, bp=0x12) at vnode_if.h:928
#18 0xc05946e6 in bufwrite (bp=0xcd838268) at buf.h:415
#19 0xc0594c31 in bawrite (bp=0x12) at buf.h:399
#20 0xc063cb82 in ffs_syncvnode (vp=0xc393a880, waitfor=3) at
/usr/src/sys/ufs/ffs/ffs_vnops.c:256
#21 0xc063b753 in ffs_sync
Re: Can kldload trigger pci bus rescan?
In message: <[EMAIL PROTECTED]@promisechina.com> <[EMAIL PROTECTED]> writes: : I tried to use kldload to load our HBA driver. But the driver's pci probe : function can not find the HBA card! Does it mean that kldload can not : trigger pci bus rescan? If so, what should I do for triggering pci bus : rescan after loading our pci driver? kldload of a driver with a pci attachment will cause all pci busses to reprobe/attach their unattached children automatically. When you say that the driver's probe function can not find the HBA card, what do you mean? That none of the devices presented to it are accepted? Warner ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Need some help on a pivot_root() syscall implementation
I have been working on an implementation of pivot_root() system call which should be a clone of the same linux system call. Description from my code (and linux/fs/namespace.c): * pivot_root Semantics: * Moves the root file system of the current process to the directory put_old, * makes new_root as the new root file system of the current process, and sets * root/cwd of all processes which had them on the current root to new_root. * * Restrictions: * The new_root must be a mountpoint and not the current root; put_old must be * under new_root and no other file system may be mounted on put_old. I have gotton as far as swapping, say, a hierarchy "/a" whith "/". The problem appears in the second part - having moved "/" to "/a/mnt" (which becomes "/mnt") when part of the fs does not work correctly. I have had versions where 'df' looks ok after pivot_root but 'ls /mnt' showed nothing, i.e. the mountpoint /mnt with the old root wasn't really there (or not visible). Now, I think I have a better version, but it panics when I do 'ls /mnt' (see below) # df Filesystem 1K-blocks Used Avail Capacity Mounted on /dev/md0 7054 5284 177075%/ devfs 1 1 0 100%/dev /dev/ad0s1a 30856 14666 1372252%/mnt /dev/md1 7054 5282 177275%/a devfs 1 1 0 100%/a/dev # usage: pivot_root new_root put_old # pivot_root /a /a/mnt pivot_root: enter pivot_root: ok, put_old has no mount points pivot_root(/a, /a/mnt): locked Giant pivot_root: start lookup new_root '/a' pivot_root: start lookup put_old '/a/mnt' pivot_root: rootvnode 0xc221cc30; put_vp 0xc2253208 new_vp 0xc222d618 pivot_root: new_mp removed and reinserted in head of mountlist pivot_root: new root adjusted pivot_root: f_mntonname /a => / pivot_root: old root mountpoint adjusted pivot_root: f_mntonname / => /mnt pivot_root: mountpoint /dev under old root adjusted pivot_root: f_mntonname /dev => /mnt/dev pivot_root: mountpoint /mnt under old root adjusted pivot_root: f_mntonname /mnt => /mnt/mnt pivot_root: mountpoint /a/dev under new root adjusted pivot_root: f_mntonname /a/dev => /dev pivot_root: mountlist adjustments done pivot_root: put_vp done pivot_root: new_vp done pivot_root: leaving, error = 0 # df Filesystem 1K-blocks Used Avail Capacity Mounted on /dev/md1 7054 5282 177275%/ /dev/md0 7054 5284 177075%/mnt devfs 1 1 0 100%/mnt/dev /dev/ad0s1a 30856 14666 1372252%/mnt/mnt devfs 1 1 0 100%/dev # ls /mnt panic: userret: Returning with 1 locks held. cpuid = 0 KDB: enter: panic [thread pid 70 tid 100040 ] Stopped at kdb_enter+0x2b: nop db> show lockedvnods Locked vnodes 0xc222d618: tag ufs, type VDIR usecount 10, writecount 0, refcount 12 mountedhere 0 flags (VV_ROOT) lock type ufs: EXCL (count 1) by thread 0xc2207360 (pid 70) ino 2, on dev md1 Does anyone have an idea what could be causing this and in which direction I should look? I can supply a patch against -current to anyone who is interested in investigatig this further together with me, just drop me an Email! Adrian ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Keyboard Boot Disable
On Tue, Apr 25, 2006 at 06:27:53PM -0400, Lucas Holt wrote: > I worked with someone once that said they blew out the ps/2 port on > the motherboard. As an alternative, maybe you could consider a kvm > switch? Maybe on an ancient motherboard?? Most motherboards have overvoltage/overcurrent protection circuitry. A PS/2 port is just a glorified serial port: 5v signals vs. +/- 7.5v. The only problem I've ever had with hot-swapping PS/2 is tricking the OS to reinitialize the device. FreeBSD seems to handle this better than most. Smart KVMs work much better because they keep the virtual device connected, and they keep keyboard initialization state so they can reinitialize the keyboard when it's plugged in again. Even dumb KVMs seem to handle hot-swapping better; likely the onboard logic behaves better than the onboard keyboard controllers. USB works much better because it guarantees power & ground connection is established before the data pins. Many KVMs buffer the keyboard I/O so it can wait until power & ground are established before trying to send/recv data. I've never blown out a PS/2 port or device, and I hot swap much more than I should... -- Rick C. Petty ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: [ANN] unionfs patchset-11 release
Fabian Keil <[EMAIL PROTECTED]> wrote: > Fabian Keil <[EMAIL PROTECTED]> wrote: > > > Daichi GOTO <[EMAIL PROTECTED]> wrote: > > > > > Fabian Keil wrote: > > What I'm doing is: > > > > [EMAIL PROTECTED] ~ $mkdir /tmp/unionfs-src/ > > [EMAIL PROTECTED] ~ $mount_unionfs /tmp/unionfs-src /usr/src > > [EMAIL PROTECTED] ~ $cd /usr/src > > [EMAIL PROTECTED] /usr/src $patch -p1 < ~/test/combi.patch > > [EMAIL PROTECTED] /usr/src $find /tmp/unionfs-src/ -type f > > [Panic] > > > > ~/test/combi.patch changes about twenty files. Not exactly: [EMAIL PROTECTED] ~ $grep +++ ~/test/combi.patch | wc -l 38 > > I'm not sure if it's important, but /usr was mounted > > readonly and /tmp is a different file system. I got the same panic with /usr mounted rewritable and both directories on the same file system this time. Running patch -p1 < ~/test/combi.patch seems to be enough to trigger the panic. I tried three runs with a smaller patch (unionfs6-p11.diff) without panic, I then took the bigger patch again and a few seconds later the system panicked. > Another thing which could be significant or not: > After my last mail I closed Xorg and tried to reproduce the > panic two times, but couldn't. After a reboot the panic > occurred right after the first attempt. I'm not sure anymore if I used the same patch the first times. Fabian -- http://www.fabiankeil.de/ signature.asc Description: PGP signature
Re: Can kldload trigger pci bus rescan?
[EMAIL PROTECTED] wrote: I tried to use kldload to load our HBA driver. But the driver's pci probe function can not find the HBA card! By this do you mean that when you have the card in the system, FreeBSD booted and you kldload the driver, you don't see kernel messages showing the appropriate attach messages? Is anything printed? > Does it mean that kldload can not trigger pci bus rescan? If so, what should I do for triggering pci bus rescan after loading our pci driver? As Daniel and Warner already stated, the PCI rescan is automatic. This is more likely an identification or driver mismatch problem. Please provide the following: - The exact make and model of the HBA card. - The exact version of FreeBSD you're using. - Which driver you're trying to use. This information will allow us to nail down possible reasons why the attach is not occuring. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Intel 6300ESB SATA - Now Tyan B5350G20S2H-LC suggestion
Well, $6k later... and the only SATA interface available are on a Adaptec AIC-8110 / HostRAID. (And the nightmare continue... I hate what Adaptec is doing with their SATA line... never worked right for me) The 6300ESB is there but its not providing SATA. Those are pricey paper weights. I'll see what I can make work with it... -- Alain Hebert[EMAIL PROTECTED] PubNIX Inc. P.O. Box 175 Beaconsfield, Quebec H9W 5T7 tel 514-990-5911 http://www.pubnix.netfax 514-990-9443 ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Jail Quotas - quota.user hard link
Hello all, I have a question about using quotas in a jail with FreeBSD 6.x. So far I have had no problems on a test box with setting quotas from the host using a numeric UID (ie: edquota -u 2 where UID 2 is a user that only exists in a jail). That seems to "just work". The problem comes when I want the jailed users to be able to see what their current usage is. I have a few jails on one partition, so the problem is that the quota.user file is outside the jail. Making a hard link to /jails/quota.user from /jails/jailX/quota.user starts to solve the problem. Only one jail actually needs this capability. Is there any problem with this technique of making a hard link to the real quota.user? One other note... I do null mount ports into two jails from another jail that is used strictly for package building (all on the same filesystem). Are there any weird nullfs/quota interactions to be aware of? Thanks, Charles ___ Charles Sprickman NetEng/SysAdmin Bway.net - New York's Best Internet - www.bway.net [EMAIL PROTECTED] - 212.655.9344 ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Disabling Tx intrerrupts in bge
Hi hackers, how do I disable Tx interrupts in the bge driver? I guess it should be by changing some bit in this mask: #define BGE_MBX_IRQ0_LO 0x0204 Any help is appreciated. wbr Vijay Singh NetApp ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Intel 6300ESB SATA - Now Tyan B5350G20S2H-LC
Well, Good and bad news... 6.1-RC works to install (thanks Soren) But BTX halt on boot: - int=000d err= efl=00030002 eip=10ce eax=000c0002 ebx= ecx=0005 edx=0100 esi=00b6 edi=03f0 ebp=3778 esp=3754 cs=c800 ds=c800 es=1400fs= gs=9880 ss=9880 cs:eip=2e 0f 01 1e 1d 11 2e 0f-01 16 23 11 0f 20 c0 66 25 ff ff ff 7f 0c 01 0f-22 c0 eb 00 0f 01 e0 a8 ss:esp=46 02 09 0e 00 00 00 00-b6 00 80 98 88 36 f0 03 b6 00 78 37 72 37 00 00-00 01 05 00 00 00 00 00 BTX halted - FYI: I failed to find the code at cs:eip in the boot0, boot1, boot2 and loader file. Looks like a bad jump to me. I've try everything... (I know of) . Upgrade the BIOS (can't find a way to upgrade the Tyan M8110 board) . Boot on array (failed) . Boot on a spare drive outside the array (failed) . Booted install, used the LiveCD and the filesystems are fine... boot files checksum matches . Changed fs from 4GB=swap, 232GB=/ to 256MB=/boot, 222GB=/, 4GB=swap (failed) Going to try booting the kernel from PXE and then mounting /dev/ar0s1a... If anybody has a hint (or Hints) let me know... -- Alain Hebert[EMAIL PROTECTED] PubNIX Inc. P.O. Box 175 Beaconsfield, Quebec H9W 5T7 tel 514-990-5911 http://www.pubnix.netfax 514-990-9443 ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Jail Quotas - quota.user hard link
On Wed, Apr 26, 2006 at 06:23:59PM -0400, Charles Sprickman wrote: > > I have a question about using quotas in a jail with FreeBSD 6.x. So far I > have had no problems on a test box with setting quotas from the host using > a numeric UID (ie: edquota -u 2 where UID 2 is a user that only > exists in a jail). That seems to "just work". Just a heads up: quotas in jails on FreeBSD 6 are pretty broken. I'll include some workarounds. Basic operation can be done by specifying a filename, available in the jail, which contains the quotas. So, on the base system, /etc/fstab contains: /dev/twed0s2f /usr/jails/foo.bar.com ufs rw,userquota=/usr/jails/foo.bar.com/usr/quotas/shell.root 2 2 and on the foo.bar.com jail, /etc/fstab contains: /dev/twed0s2f / ufs rw,userquota=/usr/quotas/shell.root,noauto 2 2 Now the problems begin. You either do chmod a+r /usr/quotas/shell.root which permits everyone on the machine to read all quotas (both quota and repquota) or chmod o-r /usr/quotas/shell.root which permits ONLY root to read any quotas. Normal users can not see their own quotas (I filed a PR on this quite some time back, nobody seems interested). This seems to be new breakage since 4.x Also, if you edquota from within the jail, it does not really take effect. You can stick an hourly cron script on the base system containing quotaoff -a quotacheck -a quotaon -a which will "fixup" the mess. Alternately, you can only use edquota from the base system which seems to mostly work. ISTR that there was something else that was odd but I'm sure somebody else will jump in and mention it. /\/\ \/\/ ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Jail Quotas - quota.user hard link
On Thu, 27 Apr 2006, Michael R. Wayne wrote: On Wed, Apr 26, 2006 at 06:23:59PM -0400, Charles Sprickman wrote: I have a question about using quotas in a jail with FreeBSD 6.x. So far I have had no problems on a test box with setting quotas from the host using a numeric UID (ie: edquota -u 2 where UID 2 is a user that only exists in a jail). That seems to "just work". Just a heads up: quotas in jails on FreeBSD 6 are pretty broken. I'll include some workarounds. Basic operation can be done by specifying a filename, available in the jail, which contains the quotas. So, on the base system, /etc/fstab contains: /dev/twed0s2f /usr/jails/foo.bar.com ufs rw,userquota=/usr/jails/foo.bar.com/usr/quotas/shell.root 2 2 and on the foo.bar.com jail, /etc/fstab contains: /dev/twed0s2f / ufs rw,userquota=/usr/quotas/shell.root,noauto 2 2 That's pretty nifty. "man fstab" confirms (at least the first part). I'm still curious if there's any harm in the symlink solution. Now the problems begin. You either do chmod a+r /usr/quotas/shell.root which permits everyone on the machine to read all quotas (both quota and repquota) or chmod o-r /usr/quotas/shell.root which permits ONLY root to read any quotas. Normal users can not see their own quotas (I filed a PR on this quite some time back, nobody seems interested). This seems to be new breakage since 4.x See, now back in 6.0, I could have sworn that I saw this. Even with the quota command setuid root inside the jail, I was getting "permission denied" errors. I'm now running a 6.1-RC from late last week and this seems to be working now. I'm not sure where to look in the kernel source to find if something changed, but my guess is someone did "fix" it. Also, if you edquota from within the jail, it does not really take effect. You can stick an hourly cron script on the base system containing quotaoff -a quotacheck -a quotaon -a which will "fixup" the mess. Alternately, you can only use edquota from the base system which seems to mostly work. That's fine, I plan to do most work from the host and only become root in the jail when necessary. ISTR that there was something else that was odd but I'm sure somebody else will jump in and mention it. The above was the main stumbling block for me. I know keeping UIDs unique across the host and all jails is probably a royal pain for some, but my use here (shell server inside a jail) really doesn't have any issues with that. Thanks, Charles /\/\ \/\/ ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]" ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Can kldload trigger pci bus rescan?
[EMAIL PROTECTED] wrote:
Hi guys:
My situation is:
(1) We are porting our HBA driver (Promise FastTrak TX4310 SoftRaid5) from
Linux to FreeBSD(6.0). Our HBA driver can work normally under Linux.
(2) At this time, I just wrote a sample driver code (see sr5.c in the
attached file) to check the driver's probe function in FreeBSD.
(3) After I successfully compiled the codes, I run "make load" (see Makefile
and load.info in the attached file) for testing.
(4) Our probe function was called indeed, but no matching pci device was
found! (Yes, I have plugged our HBA card in the system).
(5) Our HBA card information can be found by running pciconf (see
pciconf.info in the attached file).
The only two storage devices in the pciconf output are:
[EMAIL PROTECTED]:7:1: class=0x01018a card=0x74411022 chip=0x74411022
rev=0x04 hdr=0x00
vendor = 'Advanced Micro Devices (AMD)'
device = 'AMD-768 EIDE Controller'
class= mass storage
subclass = ATA
[EMAIL PROTECTED]:4:0: class=0x010400 card=0x3515105a chip=0x3515105a
rev=0x02 hdr=0x00
vendor = 'Promise Technology Inc'
class= mass storage
subclass = RAID
The first looks like the ATA controller on the motherboard. The second
is your Promise ATA RAID card. Both devices are already attached by
FreeBSD's ATA framework. You will need to patch FreeBSD's ATA framework
to not detect your card. The attached patch should do the trick (it
removes the corresponding PCI ID for your card). I tested the patch to
the point that it compiles, but I can't guarantee this will prevent the
attach or even result in a bootable kernel, so test carefully.
To apply the patch, do the following with root privileges:
cd /usr/src # Replace /usr/src with the base of your src tree.
patch If you have ata compiled into your kernel, rebuild your kernel. If
you're loading the ATA modules, you can get away with just rebuilding
the ata modules:
cd /usr/src/sys/modules/ata
make clean && make depend && make && make install
--- sys/dev/ata/ata-chipset.c.old Fri Oct 14 02:34:50 2005
+++ sys/dev/ata/ata-chipset.c Wed Apr 26 22:14:14 2006
@@ -2409,7 +2409,6 @@
{ ATA_PDC40518, 0, PRMIO, PRSATA2, ATA_SA150, "Promise PDC40518" },
{ ATA_PDC40519, 0, PRMIO, PRSATA2, ATA_SA150, "Promise PDC40519" },
{ ATA_PDC40718, 0, PRMIO, PRSATA2, ATA_SA300, "Promise PDC40718" },
- { ATA_PDC40719, 0, PRMIO, PRSATA2, ATA_SA300, "Promise PDC40719" },
{ 0, 0, 0, 0, 0, 0}};
char buffer[64];
uintptr_t devid = 0;
--- sys/dev/ata/ata-pci.h.old Fri Oct 14 02:34:50 2005
+++ sys/dev/ata/ata-pci.h Wed Apr 26 22:14:45 2006
@@ -213,7 +213,6 @@
#define ATA_PDC405180x3d18105a
#define ATA_PDC405190x3519105a
#define ATA_PDC407180x3d17105a
-#define ATA_PDC407190x3515105a
#define ATA_PDC206170x6617105a
#define ATA_PDC206180x6626105a
#define ATA_PDC206190x6629105a
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
