Re: [kde-freebsd] problem hal - k3b ?
Beni said the following on 25.04.2007 22:22: On Tuesday 24 April 2007 16:49:28 Zoran Kolic wrote: This problem appear in my system after updating system and ports on April, 06. K3b hangs either after loading splash screen or after eject wrote media from device. Aside that new atapi-cam.c is proven to work, I'd like to know if command line works or not? K3b needs cdrtools in background. What if you make iso file using mkisofs and burn it with cdrecord? Along with update all my system and kernel to 6.2-STABLE on Fri, Apr 6, I have this error message in dmesg output: acd0: DVDR ASUS DRW-1604P/1.09 at ata1-master UDMA33 acd0: FAILURE - INQUIRY ILLEGAL REQUEST asc=0x24 ascq=0x00 sks=0x48 0x00 0x01 And writing by k3b freeze ALL system, not only k3b. Old kernel with atapi-cam.c 1.42.2.2 revision (beginning of March) works fine without any error messages or freezes. K3B, cdrecord, hal and others works without any visible problems. -- Best regards, Simon Phoenix (Phoenix Lab.) --- KeyID: 0x2569D30B Fingerprint: 78FC 5C40 07CC D331 148E CC79 84B8 D514 2569 D30B --- ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: UFS: optimization changed
Caution, tutorial about ufs/ffs fragmentation, space and time optimization ahead ... :-) Oleg Gritsak wrote: I'm just curious about some possible mismatch in between documentation and reallife OS behaviour... Noticed this thing for more than two years ago in 4.X and now seing this in 6.2... I agree that the description in the manual pages is oversimplifying and slightly inaccurate. It is said in man newfs and man tunefs that threshhold for online optimization (space or time) is 8 percent. It's more complex than that. There is no simple threshold, but a hysteresis which is a function of the minsize value (the -m option to newfs(8) and tunefs(1)) and the current fragmentation of the file system. If the fragmentation grows beyond minfree-2 percent (i.e. beyond 6% for the default minfree value of 8), the file system switches to space optimization in order to reduce fragmentation, or at least avoid further fragmentation. If the fragmentation drops below half of the minfree value (i.e. 4% for the default case), it switches back to time optimization. Within the hysteresis interval (i.e. 4% to 6% in the default case), you can change the optimization with tunefs -m. Otherwise the file system selects the optimization automatically whenever it needs to allocate a new block during a write operation, overriding the tunefs setting. But actually, FreeBSD switches to SPACE far more earlier (or at least reports to system message buffer). Yes, it depends on the fragmentation, as explained Does it have any sense? As also noted in man newfs, the performance while optimizing for space fragmentation is reduced. So, why FreeBSD does this when file system is for example 50% empty and has 4-5GBs of free space? That can happen if the file system is heavily fragmented. If you need to avoid it, there are several possibilities. First, during newfs, you could set fsize == bsize (e.g. both 16K). If a fragment is the same size as a whole block, fragmentation is always 0%. However, you will possibly waste some space because a fragment is the smallest allocation unit. But disks are cheap nowadays ... Second, you could increase the minfree value with tunefs -m. For example, set it to 25%, so the hysteresis grows to cover your current fragmentation. Then use tunefs -o to manually set the optimization back to time. The obvious disadvantage is that larger part of the file system (25%) is reserved and cannot be used by non-root users, i.e. some space might be wasted. But, as above, disks are cheap nowadays ... However, note that a heavily fragmented file system can theoretically run out of allocatable free space, even if it has plenty of free space -- if that free space consists only of unused parts of fragmented blocks. It can happen in exceptional circumstances. The purpose of switching to space optimization is to avoid such a situation. Therefore, to answer your question Does it have any sense?: Yes, it does. By the way, the current fragmentation is reported by fsck during boot (dmesg -a | grep fragm if it is still in your kernel message buffer). Otherwise, type dumpfs your-file-system | head and look for the blocks and nffree values. The current fragmentation is the percent value of nffree of the total blocks, i.e. nffree * 100 / blocks. For example, this is the output from one of my file systems: $ dumpfs /dev/ad0s1f | head magic 19540119 (UFS2) timeThu Apr 26 09:40:19 2007 superblock location 65536 id [ 42d80392 3470461f ] ncg 398 size37389708blocks 36211584 bsize 16384 shift 14 mask0xc000 fsize 2048shift 11 mask0xf800 frag8 shift 3 fsbtodb 2 minfree 8% optim timesymlinklen 120 maxbsize 16384 maxbpg 2048maxcontig 8 contigsumsize 8 nbfree 973428 ndir48445 nifree 8879640 nffree 290762 bpg 11761 fpg 94088 ipg 23552 You see that blocks is 36211584 and nffree is 290762, so the current fragmentation is 0.80%. Also, the current optimization is reported in the first line (time in this case). Best regards Oliver -- Oliver Fromme, secnetix GmbH Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd What is this talk of 'release'? We do not make software 'releases'. Our software 'escapes', leaving a bloody trail of designers and quality assurance people in its wake. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Top not showing 4 cpus on 2 xeons with HT
On 25/04/07, Tom Evans [EMAIL PROTECTED] wrote: Yes, quite easily. anyone have any recent information about this? some people say HT sucks for almost all workloads, others say recent scheduler improvements make HT more useful.. is there anything reasonably authoritative? adrian ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [kde-freebsd] problem hal - k3b ?
I believe that this problem is now in kern/112119, which I am trying to attract developer attention to. mcl ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Top not showing 4 cpus on 2 xeons with HT
Adrian Chadd wrote: anyone have any recent information about this? some people say HT sucks for almost all workloads, others say recent scheduler improvements make HT more useful.. is there anything reasonably authoritative? No, because it depends on your applications and workload. for some it is better, for some it is not. Therefore it's best you try both variants on your own machine with your own applications and measure the difference. There's one rule of thumb, however: If you only have one HTT-capable processor, then a UP kernel will almost always be the better option, because the locking overhead of an SMP kernel will probably outweigh any advantages of HTT. On the other hand, if you have a real SMP system (i.e. multiple processors or cores, not counting HTT), then you will want to use an SMP kernel anyway. In that case, enabling HTT will probably not hurt -- _but_ there have been reports of some people that HTT hurts in such a case for certain kinds of applications (I think databases was one of them, but I don't remember exactly). Anyway, there are exceptions to any rule, so you should measure yourself. Personally I disable HTT on all of my machines because of the security issue (jails do _not_ help here at all!), and speed improvements -- if any -- are marginally small, according to my own measurements. In fact I had a hard time finding any reproducible measurable improvements at all for my typical workloads; consequently my decision was governed by the security issue. Best regards Oliver -- Oliver Fromme, secnetix GmbH Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd Perl will consistently give you what you want, unless what you want is consistency. -- Larry Wall ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [kde-freebsd] problem hal - k3b ?
Along with update all my system and kernel to 6.2-STABLE on Fri, Apr 6, I have this error message in dmesg output: acd0: DVDR ASUS DRW-1604P/1.09 at ata1-master UDMA33 acd0: FAILURE - INQUIRY ILLEGAL REQUEST asc=0x24 ascq=0x00 sks=0x48 0x00 0x01 And writing by k3b freeze ALL system, not only k3b. Beni confirmed that he could use command line and write a cd. That post to mean that the problem is in k3b itself. Or not? Zoran ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [kde-freebsd] problem hal - k3b ?
Mark Linimon said the following on 26.04.2007 10:56: -- I believe that this problem is now in kern/112119, which I am trying to attract developer attention to. Yes, thanks, Mark. -- Best regards, Simon Phoenix (Phoenix Lab.) --- KeyID: 0x2569D30B Fingerprint: 78FC 5C40 07CC D331 148E CC79 84B8 D514 2569 D30B --- ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [kde-freebsd] problem hal - k3b ?
Zoran Kolic said the following on 26.04.2007 17:24: Along with update all my system and kernel to 6.2-STABLE on Fri, Apr 6, I have this error message in dmesg output: acd0: DVDR ASUS DRW-1604P/1.09 at ata1-master UDMA33 acd0: FAILURE - INQUIRY ILLEGAL REQUEST asc=0x24 ascq=0x00 sks=0x48 0x00 0x01 And writing by k3b freeze ALL system, not only k3b. Beni confirmed that he could use command line and write a cd. That post to mean that the problem is in k3b itself. Or not? As for me, this is a atapi-cam problem, not k3b. (kern/112119) -- Best regards, Simon Phoenix (Phoenix Lab.) --- KeyID: 0x2569D30B Fingerprint: 78FC 5C40 07CC D331 148E CC79 84B8 D514 2569 D30B --- ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [kde-freebsd] problem hal - k3b ?
Hey, On Fri, Apr 20, 2007 at 09:43:01AM +0800, Ganbold wrote: Michael Nottebrock wrote: On Wednesday, 18. April 2007, Beni wrote: Hi List, I think I have a problem with hal(d) and k3b (version 1.0 from ports) : my whole system freezes when starting up k3b. I get the splash screen and then it all stops and a ctrl-alt-del is the only way out. My problem is the same as Beni's. Splash screen appears and hangs. I have to press power button to turn off and on my laptop. Didn't try ctrl+alt+del though. I have the same problem with my 7.0-CURRENT (yesterday). If I can assist you testing or debugging drivers please drop me an e-mail. FreeBSD 7.0-CURRENT i386 with k3b-1.0_1 / hal-0.5.8.20070403_1 Bye Ollie -- Oliver PETER, email: [EMAIL PROTECTED], ICQ# 113969174 Worker bees can leave. Even drones can fly away. The Queen is their slave. pgpVcp2ChvVRV.pgp Description: PGP signature
Alternate installers for FreeBSD for unattended installation
I'm having a difficult time developing a scripted install using sysinstall, as my target hardware is not sufficiently uniform, hostnames vary, etc. The sysinstall documentation implies that alternatives are available, and that sysinstall is not really supported any more. Where can I find these alternate installers? Do they have better support for scripted installations? Is it possible to perform the installation manually from the mfsroot image? If so, I guess I could develop a shell script that performs the installation steps. Best wishes, Matthew -- Rogues are very keen in their profession, and know already much more than we can teach them respecting their several kinds of roguery. - A. C. Hobbs in _Locks and Safes_ (1853) smime.p7s Description: S/MIME cryptographic signature
ath induced panic in -stable
In trying to update from a 6.2-release to 6-2.-stable,
I run into a nasty panic which results in a corrupt
backtrace. It looks like a cascade of panics. In
6.2-release, I initialize my ath wirelss NIC with the
following script
#! /bin/sh
ifconfig ath0 inet 192.168.0.10
ifconfig ath0 ssid My_ssid mode 11g channel 11 wepmode on
ifconfig ath0 wepkey 0xValid_WEP_key deftxkey 1
route add default 192.168.0.1
I can get to the net without a problem. However, with up-to-date
6.2-stable sources, the above script will cause a panic. In
trying various things, I've found that the mode 11g in the second
command is the guilty party. Without mode 11g, I can once
again to the net. Here's the output of a kgdb session
Unread portion of the kernel message buffer:
ifhwioctl(c0286938,c34c4c00,c3723e80,c3722000) at ifhwioctl+0xa40
ifioctl(c355a000,c0286938,c3723e80,c3722000,0,...) at ifioctl+0xc3
soo_ioctl(c3512a68,c0286938,c3723e80,c3745180,c3722000) at soo_ioctl+0x2db
ioctl(c3722000,da95ad04) at ioctl+0x396
syscall(bfbf003b,3b,bfbf003b,805d028,0,...) at syscall+0x22f
Xint0x80_syscall() at Xint0x80_syscall+0x1f
--- syscall (54, FreeBSD ELF32, ioctl), eip = 0x28149787, esp = 0xbfbfe2fc, ebp
= 0xbfbfe328 ---
KDB: enter: witness_checkorder
Dumping 511 MB (2 chunks)
chunk 0: 1MB (159 pages) ... ok
chunk 1: 511MB (130786 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) bt
#0 doadump () at pcpu.h:165
#1 0xc0477d1b in db_fncall (dummy1=-1065228384, dummy2=0,
dummy3=-1066610577, dummy4=0xda95a7c4 ??\225???l???\225???\225?\220\a)
at /usr/src/sys/ddb/db_command.c:492
#2 0xc0477b20 in db_command (last_cmdp=0xc07aef44, cmd_table=0x0,
aux_cmd_tablep=0xc0764a34, aux_cmd_tablep_end=0xc0764a38)
at /usr/src/sys/ddb/db_command.c:350
#3 0xc0477be8 in db_command_loop () at /usr/src/sys/ddb/db_command.c:458
#4 0xc04797e5 in db_trap (type=3, code=0) at /usr/src/sys/ddb/db_main.c:222
#5 0xc0573997 in kdb_trap (type=3, code=0, tf=0xda95a904)
at /usr/src/sys/kern/subr_kdb.c:473
#6 0xc06e9a24 in trap (frame=
{tf_fs = -627769336, tf_es = -1068040152, tf_ds = -1066205144, tf_edi =
9, tf_esi = -1020494300, tf_ebp = -627726012, tf_isp = -627726032, tf_ebx =
-1065345868, tf_edx = 0, tf_ecx = -1056878592, tf_eax = 31, tf_trapno = 3,
tf_err = 0, tf_eip = -1068026085, tf_cs = 32, tf_eflags = 662, tf_esp =
-627725960, tf_ss = -1067982253}) at /usr/src/sys/i386/i386/trap.c:594
#7 0xc06d7f5a in calltrap () at /usr/src/sys/i386/i386/exception.s:139
#8 0xc057371b in kdb_enter (msg=0x1f Address 0x1f out of bounds)
at cpufunc.h:60
#9 0xc057e253 in witness_checkorder (lock=0xc32c7e24, flags=9,
file=0xc075587c /usr/src/sys/vm/vm_map.c, line=3074)
at /usr/src/sys/kern/subr_witness.c:1079
#10 0xc0560a74 in _sx_xlock (sx=0xc32c7e24,
file=0xc075587c /usr/src/sys/vm/vm_map.c, line=3074)
at /usr/src/sys/kern/kern_sx.c:171
#11 0xc067c273 in _vm_map_lock_read (map=0x1f,
file=0xc1015000 Copyright (c) 1992-2007 The FreeBSD Project.\nCopyright
(c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994\n\tThe Regents
of the University of California. All rights reserved.\nFreeBSD is a re...,
line=0) at /usr/src/sys/vm/vm_map.c:453
#12 0xc067f330 in vm_map_lookup (var_map=0xda95aa6c, vaddr=134602752,
fault_typea=2 '\002', out_entry=0xda95aa70, object=0x1f,
pindex=0xc1015000, out_prot=0x1f Address 0x1f out of bounds,
wired=0xda95aa48) at /usr/src/sys/vm/vm_map.c:3074
#13 0xc06784bd in vm_fault (map=0xc32c7de0, vaddr=134602752,
fault_type=2 '\002', fault_flags=8) at /usr/src/sys/vm/vm_fault.c:235
#14 0xc06e9bae in trap_pfault (frame=0xda95ab34, usermode=0, eva=134602752)
at /usr/src/sys/i386/i386/trap.c:722
#15 0xc06e98b1 in trap (frame=
{tf_fs = -1065680888, tf_es = 40, tf_ds = -1066205144, tf_edi =
134602752, tf_esi = -1019717632, tf_ebp = -627725396, tf_isp = -627725472,
tf_ebx = 620, tf_edx = 0, tf_ecx = 155, tf_eax = 134603372, tf_trapno = 12,
tf_err = 2, tf_eip = -1066500010, tf_cs = 32, tf_eflags = 66050, tf_esp =
-1015923072, tf_ss = 155}) at /usr/src/sys/i386/i386/trap.c:435
#16 0xc06d7f5a in calltrap () at /usr/src/sys/i386/i386/exception.s:139
#17 0xc06e8056 in generic_copyout () at /usr/src/sys/i386/i386/support.s:760
Previous frame inner to this frame (corrupt stack?)
If one goes back upto the Unread portion above, on the console
I see a line about ath_ioctl, then frame #17.
--
Steve
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
ath0 induced panic additional info
By increasing the kernel message buffer, I was able to get the previous Unread portion im my last email. Unread portion of the kernel message buffer: lock order reversal: (sleepable after non-sleepable) 1st 0xc34caec0 ath0 (ath0) @ /usr/src/sys/dev/ath/if_ath.c:5210 2nd 0xc32cbe24 user map (user map) @ /usr/src/sys/vm/vm_map.c:3074 KDB: stack backtrace: kdb_backtrace(0,,c07c3e08,c07c5500,c078596c,...) at kdb_backtrace+0x29 witness_checkorder(c32cbe24,9,c075587c,c02) at witness_checkorder+0x578 _sx_xlock(c32cbe24,c075587c,c02) at _sx_xlock+0x50 _vm_map_lock_read(c32cbde0,c075587c,c02,2000246,c3722068,...) at _vm_map_lock_read+0x37 vm_map_lookup(d9753a6c,805e000,2,d9753a70,d9753a60,d9753a64,d9753a47,d9753a48) at vm_map_lookup+0x28 vm_fault(c32cbde0,805e000,2,8,c34ee180,...) at vm_fault+0x65 trap_pfault(d9753b34,0,805e000) at trap_pfault+0xce trap(c07b0008,28,c0730028,805e000,c334f400,...) at trap+0x319 calltrap() at calltrap+0x5 --- trap 0xc, eip = 0xc06e8056, esp = 0xd9753b74, ebp = 0xd9753bac --- generic_copyout(c34c8c00,c3726400,c34cab30,c0286938,0,...) at generic_copyout+0x36 ieee80211_ioctl(c34ca230,c0286938,c3726400) at ieee80211_ioctl+0xc1 ath_ioctl(c34c8c00,c0286938,c3726400) at ath_ioctl+0x190 ifhwioctl(c0286938,c34c8c00,c3726400,c34ee180) at ifhwioctl+0xa40 ifioctl(c355e000,c0286938,c3726400,c34ee180,0,...) at ifioctl+0xc3 soo_ioctl(c3516ab0,c0286938,c3726400,c3748480,c34ee180) at soo_ioctl+0x2db ioctl(c34ee180,d9753d04) at ioctl+0x396 syscall(3b,3b,3b,805d028,0,...) at syscall+0x22f Xint0x80_syscall() at Xint0x80_syscall+0x1f --- syscall (54, FreeBSD ELF32, ioctl), eip = 0x28149787, esp = 0xbfbfe2fc, ebp = 0xbfbfe328 --- KDB: enter: witness_checkorder panic: from debugger KDB: stack backtrace: Uptime: 1m1s Dumping 511 MB (2 chunks) chunk 0: 1MB (159 pages) ... ok chunk 1: 511MB (130786 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) quit mobile:root[157] exit exit Script done on Thu Apr 26 16:38:51 2007 -- Steve ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Alternate installers for FreeBSD for unattended installation
On Friday 27 April 2007 08:15, Matthew X. Economou wrote: I'm having a difficult time developing a scripted install using sysinstall, as my target hardware is not sufficiently uniform, hostnames vary, etc. The sysinstall documentation implies that alternatives are available, and that sysinstall is not really supported any more. Where can I find these alternate installers? Do they have better support for scripted installations? Is it possible to perform the installation manually from the mfsroot image? If so, I guess I could develop a shell script that performs the installation steps. You can get sysinstall to do most of the work for you and then fix things up after the fact by running a script. My install.cfg does a basic install and then untar's an image over the top which I created by doing an installworld into a chroot and installing ports into. Unfortunately you can't easily alter rc.conf because sysinstall overwrites it thinking it is an old copy. (You end up with your entries commented out). I've been working on a patch for sysinstall so you can specify it merge entries together without uncommenting the old ones but I haven't finished it yet. -- 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 pgp32wrpJxA0i.pgp Description: PGP signature
Re: kern/112119: system hangs when starts k3b on RELENG_6
Thomas Quinot wrote: * Ganbold, 2007-04-25 : Description: With atapi-cam.c (rev 1.42.2.3) when running k3b application, system completely hangs on k3b splash screen and I had to use power button only to restart the machine. Extremely strange. I can't offer any definite solution at this point, since I have no idea how this change could cause a system to hang. Here are a few possible investigation ideas: * AFAIK k3b is just a front-end for command-line tools. You should determine what exact commands are spawned by k3b to identify which of these is causing the apparent hang; * it would also be useful to enable CAM debugging options (see man 4 cam, option CAMDEBUG, and flags CAM_DEBUG_TRACE and CAM_DEBUG_SUBTRACE) and to capture all console output up to the hang (for example using a serial console) * if Scott's hunch of an interrupt storm is correct, then this issue might be related to the DMA problem described under PR 103602, so it would be useful to try the last patch I sent on that PR: http://www.freebsd.org/cgi/query-pr.cgi?pr=103602getpatch=12 * if all else fails, please let me know if the attached patch, which reverts part of rev. 1.42.2.3, changes anything. I tried your attached patch and the problem is still the same. System hangs when starts k3b. With atapi-cam.c rev. 1.42.2.2, k3b starts fine, system doesn't hang. For your information I have k3b normal startup messages with atapi-cam.c rev. 1.42.2.2. It might help to find the problem. devil# k3b Only one line in dcopserver file !: DCOPClient::attachInternal. Attach failed networkIdsList argument is NULL Only one line in dcopserver file !: DCOPClient::attachInternal. Attach failed networkIdsList argument is NULL kbuildsycoca running... devil# kdecore (KAction): WARNING: KActionCollection::KActionCollection( QObject *parent, const char *name, KInstance *instance ) k3b: (K3bCdrecordProgram) could not start /opt/schily/bin k3b: (K3bMkisofsProgram) could not start /opt/schily/bin k3b: (K3bCdrecordProgram) could not start /root/bin k3b: (K3bMkisofsProgram) could not start /root/bin k3b: (K3bExternalBinManager) Cdrecord 2.1 features: gracetime, overburn, cdtext, clone, tao, cuefile, xamix, plain-atapi, hacked-atapi, audio-stdin, burnfree k3b: (K3bExternalBinManager) 2 1 -1 seems to be cdrecord version = 1.11a02, using burnfree instead of burnproof k3b: (K3bExternalBinManager) seems to be cdrecord version = 1.11a31, support for Just Link via burnfree driveroption (BSDDeviceScan) number of matches 10 (BSDDeviceScan) add device /dev/cd0:1:0:0 (K3bDevice::Device) /dev/cd0: init() (K3bDevice::openDevice) open device /dev/pass0 succeeded. (K3bDevice::openDevice) open device /dev/pass0 succeeded. (K3bDevice::ScsiCommand) transport command 12, length: 6 (K3bDevice::ScsiCommand) transport command 46, length: 10 (K3bDevice::Device) /dev/cd0 feature: CD Mastering (K3bDevice::ScsiCommand) transport command 46, length: 10 (K3bDevice::Device) /dev/cd0 feature: CD Track At Once (K3bDevice::ScsiCommand) transport command 46, length: 10 (K3bDevice::Device) /dev/cd0 feature: CD-RW Media Write Support (K3bDevice::ScsiCommand) transport command 46, length: 10 (K3bDevice::Device) /dev/cd0 feature: DVD Read (MMC5) (K3bDevice::ScsiCommand) transport command 46, length: 10 (K3bDevice::Device) /dev/cd0 feature: DVD+R (K3bDevice::ScsiCommand) transport command 46, length: 10 (K3bDevice::Device) /dev/cd0 feature: DVD+RW (K3bDevice::ScsiCommand) transport command 46, length: 10 (K3bDevice::ScsiCommand) transport command 46, length: 10 (K3bDevice::Device) /dev/cd0 feature: DVD+R Double Layer (K3bDevice::ScsiCommand) transport command 46, length: 10 (K3bDevice::ScsiCommand) transport command 46, length: 10 (K3bDevice::ScsiCommand) transport command 46, length: 10 (K3bDevice::Device) /dev/cd0 feature: DVD-R/-RW Write (K3bDevice::ScsiCommand) transport command 46, length: 10 (K3bDevice::Device) /dev/cd0 feature: Rigid Restricted Overwrite (K3bDevice::ScsiCommand) transport command 46, length: 10 (K3bDevice::ScsiCommand) transport command 46, length: 10 (K3bDevice::ScsiCommand) transport command 46, length: 10 (K3bDevice::ScsiCommand) transport command 46, length: 10 (K3bDevice::ScsiCommand) transport command 46, length: 10 (K3bDevice::openDevice) open device /dev/pass0 succeeded. (K3bDevice::openDevice) open device /dev/pass0 succeeded. (K3bDevice::ScsiCommand) transport command 5a, length: 10 (K3bDevice::ScsiCommand) transport command 5a, length: 10 (K3bDevice::Device) /dev/cd0: dataLen: 60 (K3bDevice::Device) /dev/cd0: checking for TAO (K3bDevice::ScsiCommand) transport command 55, length: 10 (K3bDevice::Device) /dev/cd0: checking for SAO (K3bDevice::ScsiCommand) transport command 55, length: 10 (K3bDevice::Device) /dev/cd0: checking for SAO_R96P (K3bDevice::ScsiCommand) transport command 55, length: 10 (K3bDevice::Device) /dev/cd0: checking for SAO_R96R (K3bDevice::ScsiCommand) transport command 55, length: 10
Re: kern/112119: system hangs when starts k3b on RELENG_6
Thomas Quinot wrote: * Ganbold, 2007-04-25 : Description: With atapi-cam.c (rev 1.42.2.3) when running k3b application, system completely hangs on k3b splash screen and I had to use power button only to restart the machine. Extremely strange. I can't offer any definite solution at this point, since I have no idea how this change could cause a system to hang. Here are a few possible investigation ideas: * AFAIK k3b is just a front-end for command-line tools. You should determine what exact commands are spawned by k3b to identify which of these is causing the apparent hang; * it would also be useful to enable CAM debugging options (see man 4 cam, option CAMDEBUG, and flags CAM_DEBUG_TRACE and CAM_DEBUG_SUBTRACE) and to capture all console output up to the hang (for example using a serial console) * if Scott's hunch of an interrupt storm is correct, then this issue might be related to the DMA problem described under PR 103602, so it would be useful to try the last patch I sent on that PR: http://www.freebsd.org/cgi/query-pr.cgi?pr=103602getpatch=12 * if all else fails, please let me know if the attached patch, which reverts part of rev. 1.42.2.3, changes anything. I will try http://www.freebsd.org/cgi/query-pr.cgi?pr=103602getpatch=12 patch later today and let you know. thanks, Ganbold Thomas. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ath0 induced panic additional info
in message [EMAIL PROTECTED], wrote Steve Kargl thusly... By increasing the kernel message buffer, I was able to get the previous Unread portion im my last email. Unread portion of the kernel message buffer: lock order reversal: (sleepable after non-sleepable) 1st 0xc34caec0 ath0 (ath0) @ /usr/src/sys/dev/ath/if_ath.c:5210 2nd 0xc32cbe24 user map (user map) @ /usr/src/sys/vm/vm_map.c:3074 ... Oh yes, I got the problem with ath interface on mode 11g (along with WPA DHCP set in /etc/rc.conf); see LOR - ath (similar to LOR #42) on FreeBSD 6-STABLE, [EMAIL PROTECTED]. - Parv -- ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ath0 induced panic additional info
On Thu, Apr 26, 2007 at 10:44:52PM -0400, [EMAIL PROTECTED] wrote: in message [EMAIL PROTECTED], wrote Steve Kargl thusly... By increasing the kernel message buffer, I was able to get the previous Unread portion im my last email. Unread portion of the kernel message buffer: lock order reversal: (sleepable after non-sleepable) 1st 0xc34caec0 ath0 (ath0) @ /usr/src/sys/dev/ath/if_ath.c:5210 2nd 0xc32cbe24 user map (user map) @ /usr/src/sys/vm/vm_map.c:3074 ... Oh yes, I got the problem with ath interface on mode 11g (along with WPA DHCP set in /etc/rc.conf); see LOR - ath (similar to LOR #42) on FreeBSD 6-STABLE, [EMAIL PROTECTED]. It's a moot point in that the system has just reboot with -current. If anyone wants the debug kernel and core dump, drop me an email. -- Steve ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
HEADS UP: No longer need to recompile milters when upgrading
The libmilter ABI breakage which required recompiling mail filters (milters) has been fixed in the RELENG_[456] branches. It is no longer necessary to recompile mail filters compiled against an older libmilter.so shared library. Additionally, if you did recompile them already, you do not need to recompile them again. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
