Re: ATA mkIII first official patches - please test!
Søren Schmidt [EMAIL PROTECTED] writes: There is no patch for ata-all.c there is a replacement. I will eventually get that updated (so you can run cvs diff ?)... OK, thanks. DES -- Dag-Erling Smørgrav - [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 50% of packets lost only on local interfaces
On Mon, 2005-Feb-07 17:05:39 -0600, Jon Noack wrote: José M. Fandiño wrote: Jon Noack wrote: Finally, I found the culprit: CFLAGS= \ 100% of the transmited traffic is received COPTFLAGS= / CFLAGS= -pipe \ 50% of the transmited traffic is received COPTFLAGS= -pipe / It would be quite interesting to compare the actual commands that are generated: Capture the buildworld/kernel output and compare the same command in both cases. If the only difference is really just -pipe, then we need to do some more investigating. The explanation I've heard (I have no actual knowledge here, I'm just good at repeating others) is that gcc doesn't compile any ASM with -O0 (which is what you get with CFLAGS=-pipe). This Breaks Things(tm): There used to be inconsistencies in the way gcc handle asm() statements so that it could be difficult to write asm() statement constraints that worked correctly with both -O0, -O1 and -O2 but it never ignored asm() statements. (I haven't looked since about 2.95 so I'm not sure if the 3.x series fixed this problem) http://docs.freebsd.org/cgi/mid.cgi?20020623214947.J84322 The error message quoted in this article refers to the constraint problem above. The problem was not asm() was being ignored (or that incorrect code was generated) but that the compiler incorrectly reported errors (and failed to compile the code). (I recognize that function name - I spent weeks trying to come up with a constraint set that worked with both -O0 and -O1 and eventually gave up). Since you have managed to compile a kernel, I very much doubt you are running into the same problem. kern/52764 is another example: http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/52764 Again, this is a fails to compile report, not a generates incorrect code report. The code in question was written on the assumption that the compiler would do dead code removal and gcc -O0 doesn't. More generically it makes sense that gcc treat code differently with -O0 than with -O. By definition, it has to - otherwise the generated code would be the same. -- Peter Jeremy ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Please fix ucom + uplcom on -stable
Hello, My stable box panics daily with: panic: uhci_abort_xfer : not in process context I read that it's been fixed in -current. Will the fix be coming to -stable anytime soon? Dennis ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
ULE status
Hi, I saw several changes to sched_ule.c in the 5 stable branch. Beneath is one of them: http://lists.freebsd.org/pipermail/cvs-src/2005-February/039863.html Is the ULE scheduler still far from stable in RELENG_5 or not? Bye, Mipam. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ULE status
On Tuesday, 8. February 2005 13:07, Mipam wrote: Hi, I saw several changes to sched_ule.c in the 5 stable branch. Beneath is one of them: http://lists.freebsd.org/pipermail/cvs-src/2005-February/039863.html Is the ULE scheduler still far from stable in RELENG_5 or not? You can now compile a kernel with options SCHED_ULE again. How well it works is for yourself to determine :-) (I've been using it on my UP machine here since yesterday only). -- ,_, | Michael Nottebrock | [EMAIL PROTECTED] (/^ ^\) | FreeBSD - The Power to Serve | http://www.freebsd.org \u/ | K Desktop Environment on FreeBSD | http://freebsd.kde.org pgp7jI1hiX1Wv.pgp Description: PGP signature
Re: ULE status
On Tue, 8 Feb 2005, Michael Nottebrock wrote: On Tuesday, 8. February 2005 13:07, Mipam wrote: Hi, I saw several changes to sched_ule.c in the 5 stable branch. Beneath is one of them: http://lists.freebsd.org/pipermail/cvs-src/2005-February/039863.html Is the ULE scheduler still far from stable in RELENG_5 or not? You can now compile a kernel with options SCHED_ULE again. How well it works is for yourself to determine :-) (I've been using it on my UP machine here since yesterday only). Okay, so then the ULE sched is fairly stable then? But it's still not the default scheduler? Is it safe to use right now under RELENG_5 or not? Oh yes, i have smp machines, two physical cpu's and one machine with a hyperthreading cpu and i do have preemption enabled in the kernel config. Would that be still safe to try? Bye, Mipam. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ULE status
On Tue, 8 Feb 2005 13:33:04 +0100 Michael Nottebrock [EMAIL PROTECTED] wrote: On Tuesday, 8. February 2005 13:07, Mipam wrote: Hi, I saw several changes to sched_ule.c in the 5 stable branch. Beneath is one of them: http://lists.freebsd.org/pipermail/cvs-src/2005-February/039863.html Is the ULE scheduler still far from stable in RELENG_5 or not? You can now compile a kernel with options SCHED_ULE again. How well it works is for yourself to determine :-) (I've been using it on my UP machine here since yesterday only). Could you tell us again after a week ? There used to be a panic when using rtprio to raise the priority of a running process, do you know if it's fix ? -- IOnut Unregistered ;) FreeBSD user ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ULE status
On Tue, 8, 2005 14:33, Michael Nottebrock : On Tuesday, 8. February 2005 13:07, Mipam wrote: I saw several changes to sched_ule.c in the 5 stable branch. Beneath is one of them: http://lists.freebsd.org/pipermail/cvs-src/2005-February/039863.html Is the ULE scheduler still far from stable in RELENG_5 or not? You can now compile a kernel with options SCHED_ULE again. How well it works is for yourself to determine :-) (I've been using it on my UP machine here since yesterday only). Hi there I've been using only SCHED_ULE on my UP WS, even when there was #error def. It never broke, not even once :) Though I think there's trouble with SMP and/or HTT. I tried it once on a P4 and it paniced. On the other hand, using SCHED_ULE improves sound quality and general system 'response' concerning GUI... don't know 'bout performance. Regards ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ULE status
On Tue, 8, 2005 14:43, Ion-Mihai Tetcu : Could you tell us again after a week ? There used to be a panic when using rtprio to raise the priority of a running process, do you know if it's fix ? I never had those, and I usually run mplayer with rtprio 30... Though mplayer never uses much CPU, only when playing WMV9. Sorry I can't test the new patches too 'cause the WS is not available now. Regards ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ULE status
On Tuesday, 8. February 2005 13:38, Mipam wrote: Okay, so then the ULE sched is fairly stable then? But it's still not the default scheduler? It will never become the default scheduler in 5.x again. 5.x went into -STABLE mode with 4BSD, and that's why the default will remain 4BSD. Is it safe to use right now under RELENG_5 or not? As already said, you need to try *yourself*. -- ,_, | Michael Nottebrock | [EMAIL PROTECTED] (/^ ^\) | FreeBSD - The Power to Serve | http://www.freebsd.org \u/ | K Desktop Environment on FreeBSD | http://freebsd.kde.org pgp2wMMDSHfNd.pgp Description: PGP signature
Re: ULE status
On Tuesday, 8. February 2005 13:43, Ion-Mihai Tetcu wrote: There used to be a panic when using rtprio to raise the priority of a running process, do you know if it's fix ? I never got any panics with ULE back when it was available, so I can't tell. If you care about ULE, turn it on and see for yourself - more testers make better testing. -- ,_, | Michael Nottebrock | [EMAIL PROTECTED] (/^ ^\) | FreeBSD - The Power to Serve | http://www.freebsd.org \u/ | K Desktop Environment on FreeBSD | http://freebsd.kde.org pgpOaCVkIwxdC.pgp Description: PGP signature
Re: ULE status
On Tue, 8 Feb 2005, Michael Nottebrock wrote: On Tuesday, 8. February 2005 13:38, Mipam wrote: Okay, so then the ULE sched is fairly stable then? But it's still not the default scheduler? It will never become the default scheduler in 5.x again. 5.x went into -STABLE mode with 4BSD, and that's why the default will remain 4BSD. Is it safe to use right now under RELENG_5 or not? As already said, you need to try *yourself*. Okay clear, but the fact that it's in 5-stable suggests the it's stable to use, else why would it be in 5-stable. Maybe i'm completly wrong in this interpretation? Bye, Mipam. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ULE status
On Tue, 8 Feb 2005 14:00:03 +0100 Michael Nottebrock [EMAIL PROTECTED] wrote: On Tuesday, 8. February 2005 13:43, Ion-Mihai Tetcu wrote: There used to be a panic when using rtprio to raise the priority of a running process, do you know if it's fix ? I never got any panics with ULE back when it was available, so I can't tell. This was absolutely reproducible there is / was a PR on it. If you care about ULE, turn it on and see for yourself - more testers make better testing. I will do it it the weekend. Thanks. -- IOnut Unregistered ;) FreeBSD user ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: machine locks with PF (without using user dependent rules)
On Monday 07 February 2005 16:52, Emanuel Strobl wrote:
Resuming work on this, I managed to get a remote console to the box and
here's what I get with today's RELENG_5 and the following command, also I
need to set debug.mpsafenet to 0 otherwise my ruleset doesn't work (do what
it should do and does when set to 0 but not when default 1):
pfctl -F all -f /etc/pf.conf
Fatal trap 12: page fault while in kernel mode
fault virtual address = 0xdeadc1d7
fault code = supervisor read, page not present
instruction pointer = 0x8:0xc047ac48
stack pointer = 0x10:0xd0a44728
frame pointer = 0x10:0xd0a44730
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags= interrupt enabled, resume, IOPL = 0
current process = 1053 (sshd)
[thread pid 1053 tid 100081 ]
Stopped at pf_state_compare_lan_ext+0x18: movzbl 0xf9(%esi),%eax
db trace
Tracing pid 1053 tid 100081 td 0xc177e190
pf_state_compare_lan_ext(c176ca00,d0a447d8,d0a44758,c047c095,c176cac0) at
pf_state_compare_lan_ext+0x18
pf_state_tree_lan_ext_RB_FIND(c176cac0,d0a447d8,0,c176ca00,d0a448e4) at
pf_state_tree_lan_ext_RB_FIND+0x29
pf_find_state_recurse(c176ca00,d0a447d8,0,da7a,c0586400) at
pf_find_state_recurse+0x45
pf_test_state_tcp(d0a4492c,2,c176ca00,c1746b00,14) at
pf_test_state_tcp+0xb0 pf_test(2,c1586000,d0a44a1c,c19ff168,c1756720) at
pf_test+0x981
pf_check_out(0,d0a44a1c,c1586000,2,c19ff168) at pf_check_out+0x4e
pfil_run_hooks(c07f05a0,d0a44aa8,c1586000,2,c19ff168) at
pfil_run_hooks+0x15b ip_output(c1746b00,0,d0a44a74,0,0) at ip_output+0x3ef
tcp_output(c1a02710,c1744900,c076ed93,280,0) at tcp_output+0x984
tcp_usr_send(c1b5fdec,0,c1744900,0,0) at tcp_usr_send+0x239
sosend(c1b5fdec,0,d0a44c84,c1744900,0) at sosend+0x62b
soo_write(c1c5c264,d0a44c84,c1b0f680,0,c177e190) at soo_write+0x49
dofilewrite(5,8081000,a0,,) at dofilewrite+0xac
write(c177e190,d0a44d14,c,431,3) at write+0x77
syscall(2f,2f,2f,8071d88,a0) at syscall+0x137
Xint0x80_syscall() at Xint0x80_syscall+0x1f
--- syscall (4, FreeBSD ELF32, write), eip = 0x282ef73f, esp = 0xbfbfddfc,
ebp =0xbfbfde18 ---
Tell me how I can help, I'll later hand in the trace of the slef-lock when
debug.mpsafenet is 1.
Do you have pfsync compiled in? Is it up? If that's the case, can you try to
reproduce with a kernel without device pfsync, please? Can you also please
try the attached diff and see if it turns up anything - though I certainly
doubt that. Really except to see pfsync being the culprit here. Tell me if
removeing it helps. Thanks.
I'm a bit busy these days so I can't do extensive testing myself. It'd be a
great help if you could verify that I am looking at the right thing.
--
/\ Best regards, | [EMAIL PROTECTED]
\ / Max Laier | ICQ #67774661
X http://pf4freebsd.love2party.net/ | [EMAIL PROTECTED]
/ \ ASCII Ribbon Campaign | Against HTML Mail and News
Index: pf.c
===
RCS file: /usr/store/mlaier/fcvs/src/sys/contrib/pf/net/pf.c,v
retrieving revision 1.26
diff -u -r1.26 pf.c
--- pf.c 20 Jan 2005 18:07:35 - 1.26
+++ pf.c 8 Feb 2005 13:10:32 -
@@ -862,6 +862,7 @@
{
struct pf_src_node *cur, *next;
+ PF_ASSERT(MA_OWNED);
for (cur = RB_MIN(pf_src_tree, tree_src_tracking); cur; cur = next) {
next = RB_NEXT(pf_src_tree, tree_src_tracking, cur);
@@ -889,6 +890,7 @@
{
u_int32_t timeout;
+ PF_ASSERT(MA_OWNED);
if (s-src_node != NULL) {
if (--s-src_node-states = 0) {
timeout = s-rule.ptr-timeout[PFTM_SRC_NODE];
@@ -923,6 +925,7 @@
{
struct pf_state *cur, *next;
+ PF_ASSERT(MA_OWNED);
for (cur = RB_MIN(pf_state_tree_id, tree_id);
cur; cur = next) {
next = RB_NEXT(pf_state_tree_id, tree_id, cur);
pgpvd39NW0YEk.pgp
Description: PGP signature
Re[2]: interrupt routing
I am preparing a new server for production use. It contains 2 1000BaseTX NICs and 2 SCSI controllers. The interrupt assignment performed by ACPI looks kinda strange: irq24: bge0 ahd0 irq25: bge1 ahd1 How can I affect it? I mean I want all the devices use different IRQ lines. What hardware, curiously? Are all of these parts onboard? Can you post the ouptut of 'devconf'? This will show the bus associations for these devices. Its Tyan S2882 and all the devices are onboard ones. I dont know about devconf ($ locate devconf produces empty output as well) but pciconf results are as follows: [EMAIL PROTECTED]:6:0: class=0x01 card=0x005e9005 chip=0x801d9005 rev=0x10 hdr=0x00 vendor = 'Adaptec Inc' device = 'AIC-7902B Ultra320 SCSI Controller' class= mass storage subclass = SCSI [EMAIL PROTECTED]:6:1: class=0x01 card=0x005e9005 chip=0x801d9005 rev=0x10 hdr=0x00 vendor = 'Adaptec Inc' device = 'AIC-7902B Ultra320 SCSI Controller' class= mass storage subclass = SCSI [EMAIL PROTECTED]:9:0: class=0x02 card=0x164414e4 chip=0x164814e4 rev=0x03 hdr=0x00 vendor = 'Broadcom Corporation' device = 'BCM5704 NetXtreme Dual Gigabit Adapter' class= network subclass = ethernet [EMAIL PROTECTED]:9:1: class=0x02 card=0x164414e4 chip=0x164814e4 rev=0x03 hdr=0x00 vendor = 'Broadcom Corporation' device = 'BCM5704 NetXtreme Dual Gigabit Adapter' class= network subclass = ethernet The server runs i386 version of FreeBSD (5.3-RELEASE-p5) since I experienced some problems building ports on amd64 version. In many cases there are not other IRQs available to route, due to poor BIOS programming, ccorners cut in the physical board layout, etc. I think this is the case :/ The BIOS assigned all those devices IRQ10 and there is no way to change the settings... ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ULE status
On Tue, 8 Feb 2005 14:51:17 +0200 (EET) Viktor Ivanov [EMAIL PROTECTED] wrote: On Tue, Ôåâðóàðè 8, 2005 14:43, Ion-Mihai Tetcu êàçà: Could you tell us again after a week ? There used to be a panic when using rtprio to raise the priority of a running process, do you know if it's fix ? I never had those, and I usually run mplayer with rtprio 30... Though mplayer never uses much CPU, only when playing WMV9. Sorry I can't test the new patches too 'cause the WS is not available now. On changing, not running from the beginning rtprio 31 -mpayer_pid http://www.freebsd.org/cgi/query-pr.cgi?pr=71310 http://docs.freebsd.org/cgi/mid.cgi?20040303131655.24317.qmail -- IOnut Unregistered ;) FreeBSD user ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ULE status
On Tuesday, 8. February 2005 14:02, Mipam wrote: Okay clear, but the fact that it's in 5-stable suggests the it's stable to use, else why would it be in 5-stable. The changes that have been merged to stable have been tested for some time in 6-CURRENT, so they're not completely experimental, yes. Maybe i'm completly wrong in this interpretation? I'm not sure what your interpretation is. If you go by your own definition (what's in -stable should be safe to use), why do you ask at all? In any case, the ULE MFC commits are only a few days old, so there's naturally not much feedback available, good or bad. If you want to play it safe, wait a week or a month and monitor this lists for complaints before trying it yourself. -- ,_, | Michael Nottebrock | [EMAIL PROTECTED] (/^ ^\) | FreeBSD - The Power to Serve | http://www.freebsd.org \u/ | K Desktop Environment on FreeBSD | http://freebsd.kde.org pgp1zRaPb8J3h.pgp Description: PGP signature
Re: ULE status
On Tue, 8 Feb 2005, Michael Nottebrock wrote: On Tuesday, 8. February 2005 14:02, Mipam wrote: Okay clear, but the fact that it's in 5-stable suggests the it's stable to use, else why would it be in 5-stable. The changes that have been merged to stable have been tested for some time in 6-CURRENT, so they're not completely experimental, yes. Maybe i'm completly wrong in this interpretation? I'm not sure what your interpretation is. If you go by your own definition (what's in -stable should be safe to use), why do you ask at all? In any case, the ULE MFC commits are only a few days old, so there's naturally not much feedback available, good or bad. If you want to play it safe, wait a week or a month and monitor this lists for complaints before trying it yourself. Well i asked to see whether my interpretation was right and so it appears i am not right so i'll follow your advice and wait some before enabling it on some crucial machines here. I will enable it today on a less crucial machine though. :-) I though what's in -stable should be safe to use, but i wasn't sure this is the right understanding of 5-stable. Bye, Mipam. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ULE status
On Tuesday, 8. February 2005 14:22, Ion-Mihai Tetcu wrote: On Tue, 8 Feb 2005 14:51:17 +0200 (EET) Viktor Ivanov [EMAIL PROTECTED] wrote: On Tue, Ôåâðóàðè 8, 2005 14:43, Ion-Mihai Tetcu êàçà: Could you tell us again after a week ? There used to be a panic when using rtprio to raise the priority of a running process, do you know if it's fix ? I never had those, and I usually run mplayer with rtprio 30... Though mplayer never uses much CPU, only when playing WMV9. Sorry I can't test the new patches too 'cause the WS is not available now. On changing, not running from the beginning rtprio 31 -mpayer_pid Works for me (with 0, too). -- ,_, | Michael Nottebrock | [EMAIL PROTECTED] (/^ ^\) | FreeBSD - The Power to Serve | http://www.freebsd.org \u/ | K Desktop Environment on FreeBSD | http://freebsd.kde.org pgpTlAYdkU2b7.pgp Description: PGP signature
Re: ULE status
Mipam [EMAIL PROTECTED] wrote: On Tuesday, 8. February 2005 14:02, Mipam wrote: Okay clear, but the fact that it's in 5-stable suggests the it's stable to use, else why would it be in 5-stable. Maybe i'm completly wrong in this interpretation? [...] I though what's in -stable should be safe to use, but i wasn't sure this is the right understanding of 5-stable. No. There have always been things in -stable which were not stable itself. Of course, they were not enabled by default, and the documentation contained the appropriate warnings. There are always things which could perfectly be used to shot yourself in the foot. One of the well-known examples would be NULLFS and UNIONFS which were part of 3-stable and 4-stable all the time, but they weren't really stable in general (except under very limited, controlled conditions). (Note that I'm not saying anything about the stability of ULE.) Best regards Oliver -- Oliver Fromme, secnetix GmbH Co KG, Oettingenstr. 2, 80538 München Any opinions expressed in this message may be personal to the author and may not necessarily reflect the opinions of secnetix in any way. If you aim the gun at your foot and pull the trigger, it's UNIX's job to ensure reliable delivery of the bullet to where you aimed the gun (in this case, Mr. Foot). -- Terry Lambert, FreeBSD-hackers mailing list. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ULE status
On Tue, 8 Feb 2005 14:45:17 +0200 (EET) Viktor Ivanov [EMAIL PROTECTED] wrote: On Tue, Ôåâðóàðè 8, 2005 14:33, Michael Nottebrock êàçà: On Tuesday, 8. February 2005 13:07, Mipam wrote: I saw several changes to sched_ule.c in the 5 stable branch. Beneath is one of them: http://lists.freebsd.org/pipermail/cvs-src/2005-February/039863.html Is the ULE scheduler still far from stable in RELENG_5 or not? You can now compile a kernel with options SCHED_ULE again. How well it works is for yourself to determine :-) (I've been using it on my UP machine here since yesterday only). Hi there I've been using only SCHED_ULE on my UP WS, even when there was #error def. It never broke, not even once :) Though I think there's trouble with SMP and/or HTT. I tried it once on a P4 and it paniced. On the other hand, using SCHED_ULE improves sound quality and general system 'response' concerning GUI... don't know 'bout performance. By any chance does it help with copying from ata disks on different controllers ? For me on large files this brings up swap_pager: indefinite wait buffer with 4BSD. -- IOnut Unregistered ;) FreeBSD user ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
suiddir + ACL problem
Hello, I'm not able to make suiddir + acl inheritance to work together. Looking at function ufs_mkdir in sys/ufs/ufs/ufs/vnops.c I think that in fisrt step mechanism of suiddir sets owner and group of new directory and later ACL mechanism has not rights to inherit acl settings from parent directory. Am I right? And is it feature or bug? (FreeBSD 5.3-RELEASE) Session illustrating problem follows. su-2.05b$ mount ... ... /dev/ar0s1e on /samba (ufs, NFS exported, local, suiddir, soft-updates, acls) su-2.05b# cd /samba su-2.05b# mkdir abc su-2.05b# chown samba:samba abc su-2.05b# chmod 4700 abc su-2.05b# setfacl -m u:rumik:rwx abc su-2.05b# su rumik su-2.05b$ mkdir abc/dir1 su-2.05b$ touch abc/file1 su-2.05b$ ls -l abc total 2 drwsr-xr-x 2 samba samba 512 Feb 8 14:34 dir1 -rw-r--r-- 1 samba samba0 Feb 8 14:34 file1 su-2.05b$ exit exit su-2.05b# setfacl -d -m u::rwx,g::---,o::---,u:rumik:rwx abc su-2.05b# su rumik su-2.05b$ mkdir dir2 mkdir: dir2: Permission denied su-2.05b$ touch file2 touch: file2: Permission denied su-2.05b$ exit vita ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ULE status
On Tue, 8, 2005 15:58, Ion-Mihai Tetcu : I've been using only SCHED_ULE on my UP WS, even when there was #error def. It never broke, not even once :) Though I think there's trouble with SMP and/or HTT. I tried it once on a P4 and it paniced. On the other hand, using SCHED_ULE improves sound quality and general system 'response' concerning GUI... don't know 'bout performance. By any chance does it help with copying from ata disks on different controllers ? For me on large files this brings up swap_pager: indefinite wait buffer with 4BSD. Sorry, can't test this. I know my WS can't compare to a normal server and I don't have a production server running on SCHED_ULE (excuse the pun). As I said though, I tried once SCHED_ULE on a P4 with 1 CPU and HTT enabled and it paniced way too fast. That was when SCHED_ULE was #error-ed... As for rtprio, I do set it after I run mplayer, because I run it from normal user and rtprio is limited to root. Regards ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ULE status
Thanks for all comments on this topic. A good point was made upon the fact that there were always options available that weren't stable in X-stable. The docs contained appropriate warnings about it you mentioned. Cool, I wish to read the docs on ULE and possible warnings about using ULE, where can i find it? Bye, Mipam. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ULE status
On Tue, Feb 08, 2005 at 03:58:22PM +0200, Ion-Mihai Tetcu wrote: On Tue, 8 Feb 2005 14:45:17 +0200 (EET) Viktor Ivanov [EMAIL PROTECTED] wrote: On Tue, 8, 2005 14:33, Michael Nottebrock : On Tuesday, 8. February 2005 13:07, Mipam wrote: I saw several changes to sched_ule.c in the 5 stable branch. Beneath is one of them: http://lists.freebsd.org/pipermail/cvs-src/2005-February/039863.html Is the ULE scheduler still far from stable in RELENG_5 or not? You can now compile a kernel with options SCHED_ULE again. How well it works is for yourself to determine :-) (I've been using it on my UP machine here since yesterday only). Hi there I've been using only SCHED_ULE on my UP WS, even when there was #error def. It never broke, not even once :) Though I think there's trouble with SMP and/or HTT. I tried it once on a P4 and it paniced. On the other hand, using SCHED_ULE improves sound quality and general system 'response' concerning GUI... don't know 'bout performance. By any chance does it help with copying from ata disks on different controllers ? For me on large files this brings up swap_pager: indefinite wait buffer with 4BSD. That doesn't sound like a scheduler problem, rather a hardware or ata driver problem. Did you try sos' new driver yet? Kris pgpOLh0yQuUIM.pgp Description: PGP signature
Re: ULE status
Mipam [EMAIL PROTECTED] wrote: Thanks for all comments on this topic. A good point was made upon the fact that there were always options available that weren't stable in X-stable. The docs contained appropriate warnings about it you mentioned. I guess you're referring to my comment. Cool, I wish to read the docs on ULE and possible warnings about using ULE, where can i find it? So far, the ULE scheduler has not been part of any stable FreeBSD release, so it's not completely surprising that there isn't much documentation to be found. (I think it's not even mentioned in NOTES.) If you're looking for a generic description of URL and all the technical details, have a look at this paper: http://www.usenix.org/publications/library/proceedings/bsdcon03/tech/roberson.html Best regards Oliver -- Oliver Fromme, secnetix GmbH Co KG, Oettingenstr. 2, 80538 München Any opinions expressed in this message may be personal to the author and may not necessarily reflect the opinions of secnetix in any way. Unix gives you just enough rope to hang yourself -- and then a couple of more feet, just to be sure. -- Eric Allman ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Re[2]: interrupt routing
On Feb 8, 2005, at 8:20 AM, dima wrote: The BIOS assigned all those devices IRQ10 and there is no way to change the settings... I have similar issues with a Tyan S2881. Very annoying, since many interrupts are assigned to devices I don't need. I turned off everything I could in the BIOS, too. Make sure you have the latest BIOS, naturally. Vivek Khera, Ph.D. +1-301-869-4449 x806 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ULE status
On Tue, 8 Feb 2005 08:39:15 -0800 Kris Kennaway [EMAIL PROTECTED] wrote: On Tue, Feb 08, 2005 at 03:58:22PM +0200, Ion-Mihai Tetcu wrote: On Tue, 8 Feb 2005 14:45:17 +0200 (EET) Viktor Ivanov [EMAIL PROTECTED] wrote: On Tue, 8, 2005 14:33, Michael Nottebrock : On Tuesday, 8. February 2005 13:07, Mipam wrote: I saw several changes to sched_ule.c in the 5 stable branch. Beneath is one of them: http://lists.freebsd.org/pipermail/cvs-src/2005-February/039863.html Is the ULE scheduler still far from stable in RELENG_5 or not? You can now compile a kernel with options SCHED_ULE again. How well it works is for yourself to determine :-) (I've been using it on my UP machine here since yesterday only). Hi there I've been using only SCHED_ULE on my UP WS, even when there was #error def. It never broke, not even once :) Though I think there's trouble with SMP and/or HTT. I tried it once on a P4 and it paniced. On the other hand, using SCHED_ULE improves sound quality and general system 'response' concerning GUI... don't know 'bout performance. By any chance does it help with copying from ata disks on different controllers ? For me on large files this brings up swap_pager: indefinite wait buffer with 4BSD. That doesn't sound like a scheduler problem, rather a hardware or ata driver problem. I know it's not likely to be schedule issue, but it doesn't hurt to ask :-) And please don't tell me it's hardware, I've changed a few motherboards (all VIA 8235/8237) and different manufacturer / types / firmware revisions HDDs since 5.0 because after an update or another some specific combination ceased to work. It seems some kind of regression introduced sometime after 5.3 release. Did you try sos' new driver yet? Nope, I didn't have the time. Given my luck with ata it is rather prudent to back-up ~200GB before trying. -- IOnut Unregistered ;) FreeBSD user ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ULE status
I compiled my kernel with ULE this morning on my AMD64 workstation to help test. All seems good so far. Anything in particular to keep an eye on? -Mike On Tue, 8 Feb 2005, Michael Nottebrock wrote: On Tuesday, 8. February 2005 14:02, Mipam wrote: Okay clear, but the fact that it's in 5-stable suggests the it's stable to use, else why would it be in 5-stable. The changes that have been merged to stable have been tested for some time in 6-CURRENT, so they're not completely experimental, yes. Maybe i'm completly wrong in this interpretation? I'm not sure what your interpretation is. If you go by your own definition (what's in -stable should be safe to use), why do you ask at all? In any case, the ULE MFC commits are only a few days old, so there's naturally not much feedback available, good or bad. If you want to play it safe, wait a week or a month and monitor this lists for complaints before trying it yourself. -- ,_, | Michael Nottebrock | [EMAIL PROTECTED] (/^ ^\) | FreeBSD - The Power to Serve | http://www.freebsd.org \u/ | K Desktop Environment on FreeBSD | http://freebsd.kde.org -- Hard Work Often Pays Off After Time, but Laziness Always Pays Off Now. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ACPI Suspend/resume [was Re: ATA mkIII first official patches...]
Vlad Manilici wrote: Hi, Does 5-STABLE have a working acpi based suspend/resume for anyone? I have a 5-STABLE from 27.01, on an IBM R40e. Suspend to memory (-s 3) seems to work, but there is no way to resume. How do you trigger a resume?? On my IBM T42, I set hw.acpi.lid_switch_state to S3, so opening the lid is enough. If I suspend with acpiconf or the switch, pressing fn-F4 (It's got a cresent moon on it, I think IBM does the same keys on other models) or pressing the holding the power switch for a couple seconds does the trick. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ACPI Suspend/resume [was Re: ATA mkIII first official patches...]
On Tue, 08 Feb 2005 02:33:21 -0500 Vlad Manilici [EMAIL PROTECTED] wrote: How do you trigger a resume?? (In case you don't know this already) On ThinkPads, you normally press the blue Fn key to resume from suspend. If the machine is hibernated, a short (less than 4 secs?) press on the power button will resume. This is with that other OS, I don't know if these keys works in FreeBSD. I have yet to try out suspend resume on my T41. Her is a list of the Fn key combinations for T40 - T42: http://www-3.ibm.com/pc/support/site.wss/document.do?lndocid=MIGR-50023 HTH -- Regards, Torfinn Ingolfsen, Norway ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ACPI Suspend/resume [was Re: ATA mkIII first official patches...]
Date: Tue, 8 Feb 2005 02:33:21 -0500 From: Vlad Manilici [EMAIL PROTECTED] Sender: [EMAIL PROTECTED] Hi, Does 5-STABLE have a working acpi based suspend/resume for anyone? I have a 5-STABLE from 27.01, on an IBM R40e. Suspend to memory (-s 3) seems to work, but there is no way to resume. How do you trigger a resume?? A resume from hibernation is triggered by powering the unit on. It should see the valid hibernation file and load it into the system. (Don't hold the power switch as that will do a normal boot.) -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: [EMAIL PROTECTED] Phone: +1 510 486-8634 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: suiddir + ACL problem (correction)
Session illustrating problem follows. su-2.05b$ mount ... ... /dev/ar0s1e on /samba (ufs, NFS exported, local, suiddir, soft-updates, acls) su-2.05b# cd /samba su-2.05b# mkdir abc su-2.05b# chown samba:samba abc su-2.05b# chmod 4700 abc su-2.05b# setfacl -m u:rumik:rwx abc su-2.05b# su rumik su-2.05b$ mkdir abc/dir1 su-2.05b$ touch abc/file1 su-2.05b$ ls -l abc total 2 drwsr-xr-x 2 samba samba 512 Feb 8 14:34 dir1 -rw-r--r-- 1 samba samba0 Feb 8 14:34 file1 su-2.05b$ exit exit su-2.05b# setfacl -d -m u::rwx,g::---,o::---,u:rumik:rwx abc su-2.05b# su rumik su-2.05b$ mkdir dir2 mkdir: dir2: Permission denied su-2.05b$ touch file2 touch: file2: Permission denied su-2.05b$ exit Of course in the last part of session I want to create something in directory abc -bash-2.05b$ touch abc/file2 touch: abc/file2: Operation not permitted -bash-2.05b$ touch abc/dir2 touch: abc/dir2: Operation not permitted vita ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
PIOCWAIT top of loop: Operation not permitted
FreeBSD 4.10 from October: Last night, I ran the following command during a moment of high load: truss perl -V and received a screenful of the following message: PIOCWAIT top of loop: Operation not permitted Does that mean that perl was stuck in a wait state, or truss? ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re[2]: interrupt routing
On Tue, 8 Feb 2005, dima wrote: I am preparing a new server for production use. It contains 2 1000BaseTX NICs and 2 SCSI controllers. The interrupt assignment performed by ACPI looks kinda strange: irq24: bge0 ahd0 irq25: bge1 ahd1 How can I affect it? I mean I want all the devices use different IRQ lines. What hardware, curiously? Are all of these parts onboard? Can you post the ouptut of 'devconf'? This will show the bus associations for these devices. Its Tyan S2882 and all the devices are onboard ones. I dont know about devconf ($ locate devconf produces empty output as well) Oops, soory, that should be 'devinfo'. But pciconf might tell me what I want to know. but pciconf results are as follows: [EMAIL PROTECTED]:6:0: class=0x01 card=0x005e9005 chip=0x801d9005 rev=0x10 hdr=0x00 vendor = 'Adaptec Inc' device = 'AIC-7902B Ultra320 SCSI Controller' class= mass storage subclass = SCSI [EMAIL PROTECTED]:6:1: class=0x01 card=0x005e9005 chip=0x801d9005 rev=0x10 hdr=0x00 vendor = 'Adaptec Inc' device = 'AIC-7902B Ultra320 SCSI Controller' class= mass storage subclass = SCSI [EMAIL PROTECTED]:9:0: class=0x02 card=0x164414e4 chip=0x164814e4 rev=0x03 hdr=0x00 vendor = 'Broadcom Corporation' device = 'BCM5704 NetXtreme Dual Gigabit Adapter' class= network subclass = ethernet [EMAIL PROTECTED]:9:1: class=0x02 card=0x164414e4 chip=0x164814e4 rev=0x03 hdr=0x00 vendor = 'Broadcom Corporation' device = 'BCM5704 NetXtreme Dual Gigabit Adapter' class= network subclass = ethernet Ah, so they are all on the same bus. Yuck, performance is going to be sucky. Bad Tyan, no cookie. That'll also explain the limited number of interrupts available. I don't think there's anything we can do to help the situation, sadly. The server runs i386 version of FreeBSD (5.3-RELEASE-p5) since I experienced some problems building ports on amd64 version. You probably need to use the hw.physmem=2G loader tunable to get 5.3-R installed. Once installed you can upgrade to 5-STABLE which fixes the problem. In many cases there are not other IRQs available to route, due to poor BIOS programming, ccorners cut in the physical board layout, etc. I think this is the case :/ The BIOS assigned all those devices IRQ10 and there is no way to change the settings... -- Doug White| FreeBSD: The Power to Serve [EMAIL PROTECTED] | www.FreeBSD.org ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Please fix ucom + uplcom on -stable
On Tue, 8 Feb 2005, david uy wrote: Hello, My stable box panics daily with: panic: uhci_abort_xfer : not in process context I read that it's been fixed in -current. Will the fix be coming to -stable anytime soon? Fix to src/sys/dev/usb/uvscom.c was merged 6 1/2 hours ago. Make sure you have rev 1.23.2.1. -- Doug White| FreeBSD: The Power to Serve [EMAIL PROTECTED] | www.FreeBSD.org ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 5.3 - 5 : sshd multiple log entries login_getclass: unknown class 'root'
On Sun, 6 Feb 2005, Andrew Konstantinov wrote: What is the contents of /etc/nsswitch.conf? bz is telling me that if you still have 'nis' in the lines in nsswitch and you compile with NO_NIS that you'll get wierd user lookup errors. Hmm, I completely forgot about that one. :( I guess 'nis' should have been switched to 'files' whenever system is compiled with NO_NIS=true. it's not documented - sorry, will do that. change it to sth like: group: files hosts: files dns networks: files passwd: files shells: files w/o this change I can see sth like this when doing passwd auth: 'sshd[1995]: NSSWITCH(nss_method_lookup): nis, passwd_compat, endpwent, not found' But I suspect this will not help with your problem. Actually, that solves all the problems. Once I switched to your version of nsswitch.conf, all the unknown class bugs and multiple logging events have disappeared. thanks for the information (and thanks for the lib). I will check and see what can be done to prevent these problems in the future. -- Bjoern A. Zeeb bzeeb at Zabbadoz dot NeT ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: machine locks with PF (without using user dependent rules)
Am Dienstag, 8. Februar 2005 14:18 schrieb Max Laier: On Monday 07 February 2005 16:52, Emanuel Strobl wrote: [...] Do you have pfsync compiled in? Is it up? If that's the case, can you try No, I don't have pfsync in the kernel, also I don't have modules on that box. to reproduce with a kernel without device pfsync, please? Can you also please try the attached diff and see if it turns up anything - though I certainly doubt that. Really except to see pfsync being the culprit here. I tried your patch, no changes. I can panic the box with pfctl -F all -f /etc/pfconf regardless of the debug.mpsafenet state. But I don't get any panics with debug.mpsafenet=1 while normal operating. And I also cannot see any rule behaviour difference any more. For now it looks to me as if it's only the pfctl command which can panic the box, but I'll see the next days. Here is the latest traceback with your patch: Fatal trap 12: page fault while in kernel mode fault virtual address = 0xdeadc1d7 fault code = supervisor read, page not present instruction pointer = 0x8:0xc047b748 stack pointer = 0x10:0xcc6948fc frame pointer = 0x10:0xcc694904 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags= interrupt enabled, resume, IOPL = 0 current process = 35 (swi1: net) [thread pid 35 tid 100031 ] Stopped at pf_state_compare_ext_gwy+0x18: movzbl 0xf9(%esi),%eax db trace Tracing pid 35 tid 100031 td 0xc1515190 pf_state_compare_ext_gwy(c17ed000,cc6949ac,cc69492c,c047c2f2,c17ed0c4) at pf_state_compare_ext_gwy+0x18 pf_state_tree_ext_gwy_RB_FIND(c17ed0c4,cc6949ac,0,c17ed000,cc694ab8) at pf_state_tree_ext_gwy_RB_FIND+0x29 pf_find_state_recurse(c17ed000,cc6949ac,1,c1045ae0,c1743300) at pf_find_state_recurse+0x72 pf_test_state_tcp(cc694b00,1,c17ed000,c18aaa00,14) at pf_test_state_tcp+0xb0 pf_test(1,c1585800,cc694bf0,0,c174d260) at pf_test+0x981 pf_check_in(0,cc694bf0,c1585800,1,0) at pf_check_in+0x48 pfil_run_hooks(c07edc20,cc694c9c,c1585800,1,0) at pfil_run_hooks+0x15b ip_input(c18aaa00,0,c0768929,e6,c07edce0) at ip_input+0x20f netisr_processqueue(cc694cd8,246,c07c2ca0,2,c1508d40) at netisr_processqueue+0x15 swi_net(0,0,c075d0e9,269,0) at swi_net+0x8d ithread_loop(c1526300,cc694d48,c075ceca,31e,0) at ithread_loop+0x1ff fork_exit(c055d000,c1526300,cc694d48) at fork_exit+0xa9 fork_trampoline() at fork_trampoline+0x8 --- trap 0x1, eip = 0, esp = 0xcc694d7c, ebp = 0 --- I'm a bit busy these days so I can't do extensive testing myself. It'd be a great help if you could verify that I am looking at the right thing. Feel free to ask me whaetever you want me to do, at the moment I have the machine semiproductive and spare time :) Just lacking hacking knowledge :( -Harry pgpvqBGWymdd0.pgp Description: PGP signature
Re: AW: Slow Network with rl0 and 5.3
On Thursday 03 February 2005 18:46, I wrote: EVERYBODY: Could you please check if you have a rl(4) driven NIC and check if you experienced a speed degradation as well. Please let me know either way with information about the chipset on your NIC. Thanks! PR kern/61448 might apply to you. Can you try the diff offered there and follow-up with your findings? Finally found some time to look at the issue. The patch there was good, but needed some tweaking. Everybody (having problems) with rl should check this patch - please. I plan to commit it soon, so please scream if it breaks things for you. Karl, can you verify that this patch solves the issue as well (i.e. can you backout the one I send you earlier?) - Thanks! http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/61448 or: http://people.freebsd.org/~mlaier/if_rl.c.PR.patch directly. -- /\ Best regards, | [EMAIL PROTECTED] \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | [EMAIL PROTECTED] / \ ASCII Ribbon Campaign | Against HTML Mail and News pgpUC7GRsTXtb.pgp Description: PGP signature
libjava.so not found
In reply to a post I found online re: not being able to run java from command line, I found removing the /usr/bin links and recreating them solved my problem... vladdy:/usr/bin# rm javac vladdy:/usr/bin# ln -s /opt/j2sdk1.4.2_04/bin/javac javac and javac works fine thereafter... repeat as neccesary for java etc.. Just a thought -- --- Darryl Woodford ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: libjava.so not found
On Wed, Feb 09, 2005 at 12:03:25AM +, Darryl Woodford wrote: In reply to a post I found online re: not being able to run java from command line, I found removing the /usr/bin links and recreating them solved my problem... vladdy:/usr/bin# rm javac vladdy:/usr/bin# ln -s /opt/j2sdk1.4.2_04/bin/javac javac and javac works fine thereafter... repeat as neccesary for java etc.. AFAIK, javac doesn't install symlinks in /usr/bin. Also, since you seem to want the package in a nonstandard prefix you should make sure to specify PREFIX as such when compiling the port. Kris pgpq7RLgDLDsP.pgp Description: PGP signature
panic: _mtx_lock_sleep: recursed on non-recursive mutex bpf2 @ /usr/home/build/src/sys/net/bpf.c:1119
I'm getting this reproducible panic with a 5-STABLE system based on
sources from yesterday. The machine in question is an i386 SMP box.
The panic is reproducible by running an updated version of the
security/scanssh port which is based on libevent.
A crashdump is available for further investigation.
panic: _mtx_lock_sleep: recursed on non-recursive mutex bpf2 @
/usr/home/build/src/sys/net/bpf.c:1119
panic messages:
---
panic: _mtx_lock_sleep: recursed on non-recursive mutex bpf2 @
/usr/home/build/src/sys/net/bpf.c:1119
cpuid = 1
KDB: enter: panic
Dumping 511 MB
16 32 48 64 80 96 112 128 144 160 176 192 208 224 240 256 272 288 304
320 336 352 368 384 400 416 432 448 464 480 496
---
#0 doadump () at pcpu.h:159
159 pcpu.h: No such file or directory.
in pcpu.h
doadump () at pcpu.h:159
159 in pcpu.h
(kgdb) bt
#0 doadump () at pcpu.h:159
#1 0xc047fe25 in db_fncall (dummy1=0, dummy2=0, dummy3=1999,
dummy4=0xd8a60978 ózÀ)
at /usr/home/build/src/sys/ddb/db_command.c:531
#2 0xc047fbb2 in db_command (last_cmdp=0xc07aeaa4, cmd_table=0x0,
aux_cmd_tablep=0xc0776ed0,
aux_cmd_tablep_end=0xc0776ed4) at
/usr/home/build/src/sys/ddb/db_command.c:349
#3 0xc047fcc5 in db_command_loop () at
/usr/home/build/src/sys/ddb/db_command.c:455
#4 0xc0481e05 in db_trap (type=3, code=0) at
/usr/home/build/src/sys/ddb/db_main.c:221
#5 0xc05837be in kdb_trap (type=0, code=0, tf=0x1) at
/usr/home/build/src/sys/kern/subr_kdb.c:418
#6 0xc070f0a8 in trap (frame=
{tf_fs = 24, tf_es = 16, tf_ds = 16, tf_edi = 256, tf_esi = 1,
tf_ebp = -660206816, tf_isp = -660206844, tf_ebx = -660206756, tf_edx =
0, tf_ecx = -1056755712, tf_eax = 18, tf_trapno = 3, tf_err = 0, tf_eip
= -1067961200, tf_cs = 8, tf_eflags = 646, tf_esp = -1066043284, tf_ss =
-1066052328})
at /usr/home/build/src/sys/i386/i386/trap.c:576
#7 0xc06fa7ca in calltrap () at
/usr/home/build/src/sys/i386/i386/exception.s:140
#8 0x0018 in ?? ()
#9 0x0010 in ?? ()
#10 0x0010 in ?? ()
#11 0x0100 in ?? ()
#12 0x0001 in ?? ()
#13 0xd8a60b20 in ?? ()
#14 0xd8a60b04 in ?? ()
#15 0xd8a60b5c in ?? ()
#16 0x in ?? ()
#17 0xc1033000 in ?? ()
#18 0x0012 in ?? ()
#19 0x0003 in ?? ()
#20 0x in ?? ()
#21 0xc0583490 in kdb_enter (msg=0x0) at cpufunc.h:56
#22 0xc0566aee in panic (fmt=0xc075490e _mtx_lock_sleep: recursed on
non-recursive mutex %s @ %s:%d\n)
at /usr/home/build/src/sys/kern/kern_shutdown.c:550
#23 0xc055c914 in _mtx_lock_sleep (m=0xc2607b68, td=0xc3f3ae10, opts=0,
file=0x0, line=0)
at /usr/home/build/src/sys/kern/kern_mutex.c:456
#24 0xc055c510 in _mtx_lock_flags (m=0xc2607b68, opts=0,
file=0xc075e7ff /usr/home/build/src/sys/net/bpf.c, line=1119)
at /usr/home/build/src/sys/kern/kern_mutex.c:273
#25 0xc05dda38 in filt_bpfread (kn=0xc204d3fc, hint=0) at
/usr/home/build/src/sys/net/bpf.c:1119
#26 0xc0545518 in kqueue_register (kq=0xc25ff580, kev=0xd8a60c38,
td=0xc3f3ae10, waitok=1)
at /usr/home/build/src/sys/kern/kern_event.c:852
#27 0xc0544b4e in kevent (td=0xc3f3ae10, uap=0xd8a60d14) at
/usr/home/build/src/sys/kern/kern_event.c:563
#28 0xc070fa10 in syscall (frame=
{tf_fs = 47, tf_es = 47, tf_ds = 47, tf_edi = 134588416, tf_esi =
134586368, tf_ebp = -1077941928, tf_isp = -660206220, tf_ebx =
134570112, tf_edx = -1077941952, tf_ecx = -1077941888, tf_eax = 363,
tf_trapno = 12, tf_err = 2, tf_eip = 672189135, tf_cs = 31, tf_eflags =
642, tf_esp = -1077941988, tf_ss = 47})
at /usr/home/build/src/sys/i386/i386/trap.c:1001
#29 0xc06fa81f in Xint0x80_syscall () at
/usr/home/build/src/sys/i386/i386/exception.s:201
#30 0x002f in ?? ()
#31 0x002f in ?? ()
#32 0x002f in ?? ()
#33 0x0805a800 in ?? ()
#34 0x0805a000 in ?? ()
#35 0xbfbfe958 in ?? ()
#36 0xd8a60d74 in ?? ()
#37 0x08056080 in ?? ()
#38 0xbfbfe940 in ?? ()
#39 0xbfbfe980 in ?? ()
#40 0x016b in ?? ()
#41 0x000c in ?? ()
#42 0x0002 in ?? ()
#43 0x2810cacf in ?? ()
#44 0x001f in ?? ()
#45 0x0282 in ?? ()
#46 0xbfbfe91c in ?? ()
#47 0x002f in ?? ()
#48 0x in ?? ()
#49 0x in ?? ()
#50 0x in ?? ()
#51 0x in ?? ()
#52 0x137b8000 in ?? ()
#53 0xc41bd1c4 in ?? ()
#54 0xc3f3ae10 in ?? ()
#55 0xd8a60ca0 in ?? ()
#56 0xd8a60c7c in ?? ()
#57 0xc1a59000 in ?? ()
#58 0xc0579cb0 in sched_switch (td=0x805a000, newtd=0x8056080,
flags=---Can't read userspace from dump, or kernel process---
)
at /usr/home/build/src/sys/kern/sched_4bsd.c:881
Previous frame inner to this frame (corrupt stack?)
- Christian
--
Christian Brueffer [EMAIL PROTECTED] [EMAIL PROTECTED]
GPG Key: http://people.freebsd.org/~brueffer/brueffer.key.asc
GPG Fingerprint: A5C8 2099 19FF AACA F41B B29B 6C76 178C A0ED 982D
pgpVkWuWPSK4b.pgp
Description: PGP signature
Re: panic: _mtx_lock_sleep: recursed on non-recursive mutex bpf2 @ /usr/home/build/src/sys/net/bpf.c:1119
On Wed, Feb 09, 2005 at 02:08:30AM +0100, Christian Brueffer wrote: I'm getting this reproducible panic with a 5-STABLE system based on sources from yesterday. The machine in question is an i386 SMP box. The panic is reproducible by running an updated version of the security/scanssh port which is based on libevent. A crashdump is available for further investigation. Is the kernel compiled with -O2? This confuses the gdb stack trace unwinder, so you should try instead with -O. Kris pgpEsjDBlBujq.pgp Description: PGP signature
Re: panic: _mtx_lock_sleep: recursed on non-recursive mutex bpf2 @ /usr/home/build/src/sys/net/bpf.c:1119
On Tue, Feb 08, 2005 at 05:10:47PM -0800, Kris Kennaway wrote: On Wed, Feb 09, 2005 at 02:08:30AM +0100, Christian Brueffer wrote: I'm getting this reproducible panic with a 5-STABLE system based on sources from yesterday. The machine in question is an i386 SMP box. The panic is reproducible by running an updated version of the security/scanssh port which is based on libevent. A crashdump is available for further investigation. Is the kernel compiled with -O2? This confuses the gdb stack trace unwinder, so you should try instead with -O. No, it's compiled with -O. Could a custom CPUTYPE have anything to do with that? - Christian -- Christian Brueffer [EMAIL PROTECTED] [EMAIL PROTECTED] GPG Key: http://people.freebsd.org/~brueffer/brueffer.key.asc GPG Fingerprint: A5C8 2099 19FF AACA F41B B29B 6C76 178C A0ED 982D pgp9dmZSSQ1DS.pgp Description: PGP signature
Lock/reboot, no dump (ugh)
Hi folks; FreeBSD 5.3-STABLE #1: Wed Feb 2 22:57:48 CST 2005 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/KSD-SMP Sources from January 30th. Scenario: 1. Using GEOM_MIRROR to mirror two SATA drives. 2. Nightly, a third drive is used to back up, as follows: a. Check to see if the drive is visible on the SATA interface. b. If not, atacontrol attach 2 to scan the bus it is plugged into c. Verify that it is now online. d. Use gmirror insert to insert it into the mirror. e. Wait for it to sync. f. Stop critical processes (e.g. DBMS, etc) g. gmirror deactivate to remove the backup from the mirror. h. gmirror forget to clean up the RAID i. atacontrol detach 2 to detach and spin down the disk. The disk is now removeable without drama. Initially, this works fine. After a couple of days, it gets flakey. The disk is found during the attach, but the devices for everything other than the base drive are MISSING (e.g. the slice and partition table entries in /dev) Attempts to access the base device also fail with Device not configured and of course the rest of the script aborts since the disk isn't there when it tries to add it to the mirror. If you push it by trying to detach and attach a couple more times, eventually the system will just freeze up. A minute or so later, it spontaneously reboots. During the freeze the console is deader than a doornail - the CAPS key flips the light, but VT selection is dead, etc. I/O is completely quiescent during this time as well, including from the network. Sorry I don't have a crash dump from this - at least so far I've been unable to coax it into producing one. I'm going to try removing the attach/detach stuff and see if that helps, in an attempt to figure out where its getting pissed off. -- -- Karl Denninger ([EMAIL PROTECTED]) Internet Consultant Kids Rights Activist http://www.denninger.netMy home on the net - links to everything I do! http://scubaforum.org Your UNCENSORED place to talk about DIVING! http://www.spamcuda.net SPAM FREE mailboxes - FREE FOR A LIMITED TIME! http://genesis3.blogspot.comMusings Of A Sentient Mind ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: panic: _mtx_lock_sleep: recursed on non-recursive mutex bpf2 @ /usr/home/build/src/sys/net/bpf.c:1119
On Wed, Feb 09, 2005 at 02:17:34AM +0100, Christian Brueffer wrote: On Tue, Feb 08, 2005 at 05:10:47PM -0800, Kris Kennaway wrote: On Wed, Feb 09, 2005 at 02:08:30AM +0100, Christian Brueffer wrote: I'm getting this reproducible panic with a 5-STABLE system based on sources from yesterday. The machine in question is an i386 SMP box. The panic is reproducible by running an updated version of the security/scanssh port which is based on libevent. A crashdump is available for further investigation. Is the kernel compiled with -O2? This confuses the gdb stack trace unwinder, so you should try instead with -O. No, it's compiled with -O. Could a custom CPUTYPE have anything to do with that? Not AFAIK. Maybe the missing frames in your trace are OK. Kris pgpSZFc3NjRGi.pgp Description: PGP signature
AW: AW: Slow Network with rl0 and 5.3
we will test the patch today. thanks for your work. btw, we had an very interesting error with rl cards which we first thought this was related to the bug but then have to learn that there are far more possibilities. on an MSI motherboard we had 3 rl cards installed. it was possible to dump about 110 GB over the wire without any error. but after that when users (samba, http proxy ...) worked) the machine slowed down heavily, writing packet oversized errors on the console.we changed the cards against 3Com nics and 2 of them simply was dead. investigation further showed, that the pci slots on this motherboard are shared and also with acpi and different interrupts the rl´s brought the error and the 3Coms was dead. after changing the motherboard to another brand everything (with both cards) worked fine. karl -Ursprüngliche Nachricht- Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Im Auftrag von Max Laier Gesendet: Mittwoch, 09. Februar 2005 00:16 An: freebsd-stable@freebsd.org Cc: Karl M. Joch; Ísak Ben.; Dorian Büttner Betreff: Re: AW: Slow Network with rl0 and 5.3 On Thursday 03 February 2005 18:46, I wrote: EVERYBODY: Could you please check if you have a rl(4) driven NIC and check if you experienced a speed degradation as well. Please let me know either way with information about the chipset on your NIC. Thanks! PR kern/61448 might apply to you. Can you try the diff offered there and follow-up with your findings? Finally found some time to look at the issue. The patch there was good, but needed some tweaking. Everybody (having problems) with rl should check this patch - please. I plan to commit it soon, so please scream if it breaks things for you. Karl, can you verify that this patch solves the issue as well (i.e. can you backout the one I send you earlier?) - Thanks! http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/61448 or: http://people.freebsd.org/~mlaier/if_rl.c.PR.patch directly. -- /\ Best regards, | [EMAIL PROTECTED] \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | [EMAIL PROTECTED] / \ ASCII Ribbon Campaign | Against HTML Mail and News ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
