Re: Backup solution suggestions [ggated]
On Jan 17, 2008 1:31 AM, Johan Ström <[EMAIL PROTECTED]> wrote: > > Export the disk on the backup server with ggated. Bind it on the > > client > > with ggatec. Slap a GELI or GBDE encryption on top of it and then > > put a > > ZFS on top of it. > > > > You can mount/import this "remote" ZFS at will and do your zfs > > send/receive on your local box. Nothing ever leaves your box > > unencrypted. > > Now that is a cool solution! That actually sounds like something doable. > I tried it out some at home between a 6.2 box (client) and 7.0 box > (server), hosting the system in a ZFS "sparse volume" with a > predefined size, exported that via ggated and connected ggatec on the > client box. I then did some experimentation with just newfs, and it > worked great! > The only downside with this would be that the size is fixed. So I > played around a bit with setting the volsize property in ZFS and it > seemd to work just fine. zfs list reported the new, bigger, size. > Restarted ggatec and did a growfs, and then remounted.. Yay bigger > disk :) > Then I went on do do some geli test, geli'ed /dev/ggate0 and > newfs'ed, mounted and played around a bit. All fine.. Now came the > problem, i unmounetd it, expanded the zfs volume a bit more, > restarted ggatec and tried to attach it using geli again (note, I > have no idea if this is supposed to work at all, I'm just testing. > Havent read such things anywhere). Now I got Invalid argument. > Im not realy sure about how GEOM works, but if I recall correct it > uses the last sectors of the disk? If I moved X bytes of data from > old end of disk to new end of disk, would that make GELI work? If I > can get that to work, then this would be a kickass solution (all > encryption stuff works great, I don't have to allocate all space > immediatly, I can expand it later without destroying data and > starting from scratch etc). I'm pretty certain that GELI cannot handle variable sized disks. But you could add GVIRSTOR into the mix. But I'd just allocate the necessary space and be done with it. Adding yet another layer is asking for trouble, imho. > Some other questions, more related to ggated/c. Is this stable? Good > working? how does it handle failure situations? Anyone using it for > production systems? >From my personal experience (which is rather limited): No, barely, bad, hell >no. There were/are some open PRs about ggate. I had troubles with gmirror+ggate in that it would deadlock every other hour on SMP systems (try removing option PREEMPTION if that bug hits you). > Yes this is for backup only so minor glitches > might be acceptable for me, but I'd rather know about those beforehand. Give it a shot, if your systems stay up and stable, good. If the link breaks from time to time, I think ZFS should be able to recover most of it. Since it is your backup, I'd try to break it in interessting ways first, to get a feel for how robust it is. Uli ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Kernel panic when kldunload acpi_video
On Wed, 16 Jan 2008 09:31:55 -0500
John Baldwin <[EMAIL PROTECTED]> wrote:
> Please get a crash dump with matching kernel.debug and acpi_video.ko.debug.
where do I read about creating a debug version of acpi_video.ko (or other .kos
for that matter)?
thx!
B
_
{Beto|Norberto|Numard} Meijome
The Feynman Problem-Solving Algorithm:
(1) write down the problem.
(2) think very hard.
(3) write down the answer.
-- Murray Gell-Mann
I speak for myself, not my employer. Contents may be hot. Slippery when wet.
Reading disclaimers makes you go blind. Writing them is worse. You have been
Warned.
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
PCI MSI (was Re: What current Dell Systems are supported/work)
in message <[EMAIL PROTECTED]>, wrote Vivek Khera thusly... > > > On Jan 10, 2008, at 11:09 AM, John Baldwin wrote: > >>> *: This is the default behavior for 7.0, I have not encountered >>> the problem mentioned above on any 1950/2950 boxes so far I have >>> tested. >> >> I will enable MSI by default on 6.x now (so will take affect for >> 6.4). We've also enabled it by default on 6.x at work. >> > > Where can one go to read up on what MSI is and how it helps us? > > Is enabling it just setting a sysctl? Does that have to be done > in loader.conf or can it happen later? Speaking of MSI being on by default in recent 6-STABLE ... well, that caused my ThinkPad T61 (8859-CTO) ... dmesg: http://www103.pair.com/parv/comp/unix/freebsd/thinkpad-t61-8859-cto/sys/dmesg kernel (combined for easy perusal): http://www103.pair.com/parv/comp/unix/freebsd/thinkpad-t61-8859-cto/cf/kern/combined/T61-SMP.debug--combined /boot/device.hints: http://www103.pair.com/parv/comp/unix/freebsd/thinkpad-t61-8859-cto/cf/boot/device.hints ... to go in panic[0]. So, for now I have added ... # Since MSI turned on by default on 2008.01.10.21.17.12 UTC, # causes panic so disable MSI. hw.pci.enable_msix=0 hw.pci.enable_msi=0 ... to /boot/loader.conf. [0] I could not save the dump for neither do I have access to serial console, nor could the file system be mounted. Missing also here is a digital camera. If anybody is interested, I could write screen down, and repeat to them. - Parv -- ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: panic: vm_fault: fault on nofualt entry, addr: 81423000
following up my own email here, but I have compiled the kernel debugger into my kerenal, and much to my surprise it dooes actualy drop into the debugger when it panics. so, what can I do from there to help sort this out ? a quick backtrace shows the following call sequence: madt_probe apic_init mi_startup beging Which surprises me as I was expecting to see something inside an acpi call. I am not sure where to go from here though - I know nothing about this bit of the kernel, and it's quite a shallow learning curve unfortunately. -pete. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Dell PERC6?
On 1/17/08, Ferdinand Goldmann <[EMAIL PROTECTED]> wrote: > Hi! > > I am in the process of buying new Dell hardware, mainly the 2950 III. > According to various postings I found, the PERC6/i Controller _should_ work > with FreeBSD 6.3. Does anyone successfully use a 2950 III with PERC6/i > controller and can confirm this? > > Sorry if the question sounds stupid, but as I cannot find any references to > the PERC6 in either documentation or source code I am a bit confused, and I > wanted to make sure it works before shelling out my employers money. :-) > > Many thanks for any enlightenment on this subject, > kind regards, > Ferdinand Don't know if this is useful to you, but I'm using 7.0 on the same Dell platform, and hence on the same controller, with very good results. I think the mfi(4) manpage should be updated too :) > -- > >> Ferdinand Goldmann > >> Johannes Kepler University Linz - Server Systems/ZID > >> Mail: [EMAIL PROTECTED] Phone: 00437024689398 Fax: 00437024689397 > ___ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "[EMAIL PROTECTED]" > -- Mahnahmahnah! ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Dell PERC6?
Ferdinand Goldmann wrote: Hi! I am in the process of buying new Dell hardware, mainly the 2950 III. According to various postings I found, the PERC6/i Controller _should_ work with FreeBSD 6.3. Does anyone successfully use a 2950 III with PERC6/i controller and can confirm this? Sorry if the question sounds stupid, but as I cannot find any references to the PERC6 in either documentation or source code I am a bit confused, and I wanted to make sure it works before shelling out my employers money. :-) Many thanks for any enlightenment on this subject, kind regards, Ferdinand Hi, I have just pulled a new one out of a the box and done a boot and partition test on it using 6.3-RC2 boot only CD. Seemed to work just fine. I haven't got any PERC6/i's in production at this stage so can really say about their stability/performance just that they appear to work just fine with the 10 minute test I just did. Tom ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Dell PERC6?
Hi! I am in the process of buying new Dell hardware, mainly the 2950 III. According to various postings I found, the PERC6/i Controller _should_ work with FreeBSD 6.3. Does anyone successfully use a 2950 III with PERC6/i controller and can confirm this? Sorry if the question sounds stupid, but as I cannot find any references to the PERC6 in either documentation or source code I am a bit confused, and I wanted to make sure it works before shelling out my employers money. :-) Many thanks for any enlightenment on this subject, kind regards, Ferdinand -- >> Ferdinand Goldmann >> Johannes Kepler University Linz - Server Systems/ZID >> Mail: [EMAIL PROTECTED] Phone: 00437024689398 Fax: 00437024689397 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Dell PERC6?
On Thu, Jan 17, 2008 at 01:59:36PM +0100, Ferdinand Goldmann wrote: > I am in the process of buying new Dell hardware, mainly the 2950 III. > According to various postings I found, the PERC6/i Controller _should_ work > with FreeBSD 6.3. Does anyone successfully use a 2950 III with PERC6/i > controller and can confirm this? You'd be best off with RELENG_7 and not 6.3, but yes, the controller in question should work on RELENG_6 and RELENG_6_3. > Sorry if the question sounds stupid, but as I cannot find any references to > the PERC6 in either documentation or source code I am a bit confused, and I > wanted to make sure it works before shelling out my employers money. :-) There's been recent discussions on -stable about performance issues with mfi(4) under certain drive configuration conditions. Here's the thread: http://lists.freebsd.org/pipermail/freebsd-stable/2007-December/038755.html http://lists.freebsd.org/pipermail/freebsd-stable/2008-January/039568.html See specifically these two posts: http://lists.freebsd.org/pipermail/freebsd-stable/2008-January/039574.html http://lists.freebsd.org/pipermail/freebsd-stable/2008-January/039660.html -- | Jeremy Chadwickjdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
cd(4) as compared to acd(4)
It seems that cd driver lacks couple of useful features as compared to acd: 1. device nodes for individual tracks: this might not be so useful for tracks on audio CDs, but it is especially useful for mixed audio/data CDs and multi-track data CDs; 2. automatic detection of track type (audio/data) and then using proper READ command (e.g. READ CD) in strategy, so that read(2) works even for audio CDs (convenient and easy way of doing digital audio extraction); The second one also breaks "API" compatibility between the drivers: if you want to do digital audio extraction, you have to know underlying device type and use different techniques. It seems that these features are not terribly hard to implement (using acd as an example). I am not volunteering at this moment, but this could be added to some "junior hacker tasks" list. -- Andriy Gapon ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: What current Dell Systems are supported/work
Vivek Khera wrote: On Jan 15, 2008, at 1:40 PM, John Baldwin wrote: Where can one go to read up on what MSI is and how it helps us? Is enabling it just setting a sysctl? Does that have to be done in loader.conf or can it happen later? loader.conf (though it is now default on in RELENG_6). hw.pci.msi_enable=1 hw.pci.msix_enable=1 Thanks for the info. But can anyone point me to some documentation on why MSI is good for me? When implemented and used correctly in the hardware and driver, it a lower overhead interrupt mechanism. It also expands the number of interrupt vectors available, making interrupt sharing non-existent (for right now, at least). Thirdly, it vastly simplifies interrupt routing and makes a lot of problems with missing interrupts at the OS/driver level go away. Scott ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: What current Dell Systems are supported/work
Vivek Khera wrote: On Jan 15, 2008, at 1:40 PM, John Baldwin wrote: Where can one go to read up on what MSI is and how it helps us? Is enabling it just setting a sysctl? Does that have to be done in loader.conf or can it happen later? loader.conf (though it is now default on in RELENG_6). hw.pci.msi_enable=1 hw.pci.msix_enable=1 Thanks for the info. But can anyone point me to some documentation on why MSI is good for me? When implemented and used correctly in the hardware and driver, it a lower overhead interrupt mechanism. It also expands the number of interrupt vectors available, making interrupt sharing non-existent (for right now, at least). Scott ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: What current Dell Systems are supported/work
On Jan 15, 2008, at 1:40 PM, John Baldwin wrote: Where can one go to read up on what MSI is and how it helps us? Is enabling it just setting a sysctl? Does that have to be done in loader.conf or can it happen later? loader.conf (though it is now default on in RELENG_6). hw.pci.msi_enable=1 hw.pci.msix_enable=1 Thanks for the info. But can anyone point me to some documentation on why MSI is good for me? ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: 7.0-PRERELEASE desktop system periodically freezes momentarily
On Mon, 2008-01-14 at 21:06 +0100, Kris Kennaway wrote: > Same deal as before then. It cannot be the same problem as in the > previous 6.x trace (unless you are using a non-mpsafe filesystem, i.e. > not UFS). > > Kris In fact I have some MSDOSFS auto-mounting from /etc/fstab, but normally not in active use (by me - as for what gnome-* are doing in the background?). Without those mounts the stuttering in glxgears when 'Harddisk' is enabled in System Monitor is barely perceptible. The stuttering with Network Monitor remains as do the other freezes. I didn't have the same luck getting nvidia-driver working with LOCK_PROFILING in RELENG_7 as I did with MUTEX_PROFILING in RELENG_6. Looks like I'll have to test with nv or vesa driver instead, now. I've also prepared a KTR testing kernel but in the process realise I don't know which trace classes to include? Wayne ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
nscd again
Hello! I found some strange behaviour of NIS/nscd when NIS in compat mode. In /etc/nsswitch.conf I have: netgroup: cache compat passwd: cache compat group:cache compat #group_compat: cache nis #passwd_compat:cache nis in /etc/nscd.conf: #nscd.conf threads 16 enable-cache passwd yes keep-hot-count passwd 20480 positive-time-to-live passwd 36000 enable-cache group yes keep-hot-count group 20480 positive-time-to-live group 36000 enable-cache group_compat yes keep-hot-count group_compat 20480 positive-time-to-live group.byname 36000 enable-cache passwd_compat yes keep-hot-count passwd_compat 20480 positive-time-to-live passwd_compat 36000 enable-cache netgroup yes keep-hot-count netgroup 20480 positive-time-to-live netgroup 36000 But, when I do some actions on NIS-client host (host with ypbind), host ignoring cached data. In ypserv debug log: ... ypserv: retrieving next key, previous was: [XXX] ypserv: result of lookup: key: [X] data: [XX:*:1168:] ypserv: procedure ypproc_next called from XXX.XXX.XXX.XXX:739 ypserv: client is referencing map "group.byname". ypserv: retrieving next key, previous was: [XXX] ypserv: result of lookup: key: [baytin] data: [XX:*:1220:] ypserv: procedure ypproc_next called from XXX.XXX.XXX.XXX:739 ypserv: client is referencing map "group.byname". ypserv: retrieving next key, previous was: [XX] ypserv: result of lookup: key: [] data: [:*:3012:] ypserv: procedure ypproc_next called from XXX.XXX.XXX.XXX:739 ypserv: client is referencing map "group.byname". ypserv: retrieving next key, previous was: [] ypserv: result of lookup: key: [XXX] data: [XXX:*:3021:] ypserv: procedure ypproc_next called from XXX.XXX.XXX.XXX:739 ypserv: client is referencing map "group.byname". ypserv: retrieving next key, previous was: [XXX] ypserv: result of lookup: key: [vereschagin] data: [XXX:*:3024:] ypserv: procedure ypproc_next called from XXX.XXX.XXX.XXX:739 ypserv: client is referencing map "group.byname". ypserv: retrieving next key, previous was: [XXX] ... If I set in nsswitch.conf: netgroup: cache compat passwd: cache compat group:cache compat group_compat: cache nis passwd_compat:cache nis I have other errors: Jan 17 21:53:13 mfas002 sudo: NSSWITCH(nss_method_lookup): cache, passwd_compat, setpwent, not found Jan 17 21:53:15 mfas002 sudo: NSSWITCH(nss_method_lookup): cache, group_compat, setgrent, not found Jan 17 21:53:15 mfas002 sudo: NSSWITCH(nss_method_lookup): cache, group_compat, getgrent_r, not found Jan 17 21:53:15 mfas002 last message repeated 197 times Jan 17 21:53:15 mfas002 sudo: NSSWITCH(nss_method_lookup): cache, group_compat, endgrent, not found Jan 17 21:53:15 mfas002 sudo: NSSWITCH(nss_method_lookup): cache, passwd_compat, endpwent, not found Jan 17 21:53:15 mfas002 sudo: NSSWITCH(nss_method_lookup): cache, group_compat, endgrent, not found Seems group_compat and passwd_compat databases can't operate with cache sourse. Is that true? -- Denis Barov| /"\ Yandex WEB-Search Administration Team | \ / ASCII Ribbon Campaign phone: : +7 (495) 739-70-00 add. 7154 | X NO HTML/RTF in e-mail e-mail: [EMAIL PROTECTED] | / \ NO Word docs in e-mail ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: 7.0-PRERELEASE desktop system periodically freezes momentarily
Wayne Sierke wrote: On Mon, 2008-01-14 at 21:06 +0100, Kris Kennaway wrote: Same deal as before then. It cannot be the same problem as in the previous 6.x trace (unless you are using a non-mpsafe filesystem, i.e. not UFS). Kris In fact I have some MSDOSFS auto-mounting from /etc/fstab, but normally not in active use (by me - as for what gnome-* are doing in the background?). Without those mounts the stuttering in glxgears when 'Harddisk' is enabled in System Monitor is barely perceptible. The stuttering with Network Monitor remains as do the other freezes. I didn't have the same luck getting nvidia-driver working with LOCK_PROFILING in RELENG_7 as I did with MUTEX_PROFILING in RELENG_6. Looks like I'll have to test with nv or vesa driver instead, now. I've also prepared a KTR testing kernel but in the process realise I don't know which trace classes to include? KTR_SCHED Kris ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Dell PERC6?
Vlad GALU writes: | On 1/17/08, Ferdinand Goldmann <[EMAIL PROTECTED]> wrote: | > Hi! | > | > I am in the process of buying new Dell hardware, mainly the 2950 III. | > According to various postings I found, the PERC6/i Controller _should_ work | > with FreeBSD 6.3. Does anyone successfully use a 2950 III with PERC6/i | > controller and can confirm this? | > | > Sorry if the question sounds stupid, but as I cannot find any references to | > the PERC6 in either documentation or source code I am a bit confused, and I | > wanted to make sure it works before shelling out my employers money. :-) | > | > Many thanks for any enlightenment on this subject, | > kind regards, | > Ferdinand | |Don't know if this is useful to you, but I'm using 7.0 on the same | Dell platform, and hence on the same controller, with very good | results. I think the mfi(4) manpage should be updated too :) It's been updated in -current. Yes, PERC6 support is in 6.3 & 7.0. Thanks for the prompt, Doug A. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: 7.0-PRERELEASE desktop system periodically freezes momentarily
Kris Kennaway wrote: > KTR_SCHED Kris, BTW, I am curious if the traces I posted were informative. Let me know if I did not create them correctly. The xterm test seems to vary in usefulness depending on video card (faster cards catch up too quickly), but the freezing still happens quite often using apps like firefox, especially. Here's the post link: http://lists.freebsd.org/pipermail/freebsd-stable/2008-January/039599.html Thanks, Joe ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: panic: vm_fault: fault on nofualt entry, addr: 81423000
On Thursday 17 January 2008 07:38:32 am Pete French wrote: > following up my own email here, but I have compiled the kernel > debugger into my kerenal, and much to my surprise it dooes actualy > drop into the debugger when it panics. > > so, what can I do from there to help sort this out ? a quick backtrace > shows the following call sequence: > > madt_probe > apic_init > mi_startup > beging > > Which surprises me as I was expecting to see something inside an acpi call. > I am not sure where to go from here though - I know nothing about this bit > of the kernel, and it's quite a shallow learning curve unfortunately. MADT is the ACPI table that enumerates APICs. Do you have the offset of madt_probe()? -- John Baldwin ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Kernel panic when kldunload acpi_video
On Thursday 17 January 2008 06:17:52 am Norberto Meijome wrote: > On Wed, 16 Jan 2008 09:31:55 -0500 > John Baldwin <[EMAIL PROTECTED]> wrote: > > > Please get a crash dump with matching kernel.debug and acpi_video.ko.debug. > > where do I read about creating a debug version of acpi_video.ko (or other .kos for that matter)? If you use config -g it will build debug versions of kernel + modules. To build a debug module from /sys/modules/foo use 'make DEBUG_FLAGS=-g'. -- John Baldwin ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: PCI MSI (was Re: What current Dell Systems are supported/work)
On Thursday 17 January 2008 06:05:17 am Parv wrote: > in message <[EMAIL PROTECTED]>, > wrote Vivek Khera thusly... > > > > > > On Jan 10, 2008, at 11:09 AM, John Baldwin wrote: > > > >>> *: This is the default behavior for 7.0, I have not encountered > >>> the problem mentioned above on any 1950/2950 boxes so far I have > >>> tested. > >> > >> I will enable MSI by default on 6.x now (so will take affect for > >> 6.4). We've also enabled it by default on 6.x at work. > >> > > > > Where can one go to read up on what MSI is and how it helps us? > > > > Is enabling it just setting a sysctl? Does that have to be done > > in loader.conf or can it happen later? > > Speaking of MSI being on by default in recent 6-STABLE ... well, > that caused my ThinkPad T61 (8859-CTO) ... > > dmesg: > http://www103.pair.com/parv/comp/unix/freebsd/thinkpad-t61-8859-cto/sys/dmesg > > kernel (combined for easy perusal): > http://www103.pair.com/parv/comp/unix/freebsd/thinkpad-t61-8859-cto/cf/kern/combined/T61-SMP.debug--combined > > /boot/device.hints: > http://www103.pair.com/parv/comp/unix/freebsd/thinkpad-t61-8859-cto/cf/boot/device.hints > > > ... to go in panic[0]. So, for now I have added ... > > # Since MSI turned on by default on 2008.01.10.21.17.12 UTC, > # causes panic so disable MSI. > hw.pci.enable_msix=0 > hw.pci.enable_msi=0 > > > ... to /boot/loader.conf. > > > [0] I could not save the dump for neither do I have access to > serial console, nor could the file system be mounted. Missing > also here is a digital camera. If anybody is interested, I > could write screen down, and repeat to them. For starters, can you get the output of 'pciconf -lc'? Secondly, I really will need the kernel panic message. If it is a page fault (trap 12) then write down the faulting virtual address and the faulting IP. If you can scribble down any of the stack trace from DDB that would be helpful as well. -- John Baldwin ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: kldstat causes kernel to print odd message
On Wednesday 16 January 2008 10:40:25 pm Daniel O'Connor wrote: > Hi, > I have built my own release of 6.3 (slightly older than 6.3 as tagged) > and I am seeing an odd cosmetic problem. Whenever I kldload a module > (stuff loaded by the loader doesn't do it) I get this in dmesg.. > kldload: Unsupported file type > > The actual module works fine though (shows up in kldstat etc) > Can anyone explain what the underlying problem is? (I am guessing some > ordering issue where normally elf64_obj is called first so the other is > normally never called..) > > Thanks. amd64 uses link_elf_obj.c, all the other archs use link_elf.c, hence the duplication. link_elf.c is used to load kld's that are ELF shared objects (i.e. foo.so) where as link_elf_obj.c is used to load kld's that are ELF objects (i.e. foo.o). I think you are going to get this everytime you do a kldload on amd64 because it will always try link_elf.c first due to compile order (MI files are ordered in the makefile before MD ones), emit the warning, and then try link_elf_obj.c. -- John Baldwin ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
garbled message from p800-controller
Hi. I've upgraded to FreeBSD stable as of Jan. 16'th 2008, doen a make world/kernel. The server is a DL360 G5 with a builtin p400i controller and a p800 controller as well. Upon boot I get a garbled dmesg from the p800 controller: da1 at ciss1 bus 0 target 0 lun 0 dSaM1P:: A Fixed Direct Access SCSI-5 device da1: 135.168MB/s transfers I recall a similar thread was brought up just before xmas but I can't find the thread. -- regards Claus When lenity and cruelty play for a kingdom, the gentlest gamester is the soonest winner. Shakespeare ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: garbled message from p800-controller
On Thu, Jan 17, 2008 at 10:24:55PM +0100, Claus Guttesen wrote: > Hi. > > I've upgraded to FreeBSD stable as of Jan. 16'th 2008, doen a make > world/kernel. The server is a DL360 G5 with a builtin p400i controller > and a p800 controller as well. Upon boot I get a garbled dmesg from > the p800 controller: > > da1 at ciss1 bus 0 target 0 lun 0 > dSaM1P:: A ME expa> Fixed Direct Access SCSI-5 device > da1: 135.168MB/s transfers > > I recall a similar thread was brought up just before xmas but I can't > find the thread. > It is just two separate lines getting mixed together. One of them is "SMP: AP CPU #1 Launched!", i.e. the second CPU/core was just started and it wrote a message to the console announcing that at the same time as the first CPU wrote "da1: Fixed Direct Access SCSI-5 device" to the console. -- Erik Trulsson [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: kldstat causes kernel to print odd message
On Fri, 18 Jan 2008, John Baldwin wrote: > > Can anyone explain what the underlying problem is? (I am guessing > > some ordering issue where normally elf64_obj is called first so the > > other is normally never called..) > > amd64 uses link_elf_obj.c, all the other archs use link_elf.c, hence > the duplication. link_elf.c is used to load kld's that are ELF > shared objects (i.e. foo.so) where as link_elf_obj.c is used to load > kld's that are ELF objects (i.e. foo.o). I think you are going to > get this everytime you do a kldload on amd64 because it will always > try link_elf.c first due to compile order (MI files are ordered in > the makefile before MD ones), emit the warning, and then try > link_elf_obj.c. OK, that was my guess - the thing is that the last release I made didn't do this and I don't have any special options in the release or anything. I guess one option would be to put #ifdef amd64 around the error message in link_elf.c. -- 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 signature.asc Description: This is a digitally signed message part.
Re: 6.3-RELEASE
On Thu, Jan 17, 2008 at 01:59:01PM -0800, Josef Grosch wrote: > I have a mirror at work (Juniper Networks) and we have had all the > bits since Tuesday. You can't have; the final sparc64-6 packages were just finished yesterday, at the last second. mcl ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: 6.3-RELEASE
Quoting Josef Grosch, who wrote on Thu, Jan 17, 2008 at 01:59:01PM -0800 .. > On Tue, Jan 15, 2008 at 02:25:43PM -0600, Mark Linimon wrote: > > On Tue, Jan 15, 2008 at 09:51:13PM +0200, George Kontostanos wrote: > > > So may I guess that we have a release ? > > > > This question happens every time we get near a release. > > > > There will be a release when, and only when, a signed email is sent from > > the Release Engineering team to the various mailing lists. In the meantime, > > final preparations are being made, such as giving the mirrors time to get > > the bits, so that they will be there when the announcement goes out. > > > > Please be patient. > > > > mcl > > How long does it take to get all the mirrors ready? I have a mirror at work > (Juniper Networks) and we have had all the bits since Tuesday. We are Interesting, given that I only finished uploading the Alpha dist CD images today. And pc98 I think was uploaded yesterday. -- Wilko Bulte [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: 6.3-RELEASE
On Tue, Jan 15, 2008 at 02:25:43PM -0600, Mark Linimon wrote: > On Tue, Jan 15, 2008 at 09:51:13PM +0200, George Kontostanos wrote: > > So may I guess that we have a release ? > > This question happens every time we get near a release. > > There will be a release when, and only when, a signed email is sent from > the Release Engineering team to the various mailing lists. In the meantime, > final preparations are being made, such as giving the mirrors time to get > the bits, so that they will be there when the announcement goes out. > > Please be patient. > > mcl How long does it take to get all the mirrors ready? I have a mirror at work (Juniper Networks) and we have had all the bits since Tuesday. We are really looking forward to 6.3 Josef -- Josef Grosch | Another day closer to a | FreeBSD 6.2 [EMAIL PROTECTED] | Micro$oft free world | Berkeley, Ca. pgpgvie0DtbuM.pgp Description: PGP signature
Re: 6.3-RELEASE
On Thu, Jan 17, 2008 at 04:17:33PM -0600, Mark Linimon wrote: > On Thu, Jan 17, 2008 at 01:59:01PM -0800, Josef Grosch wrote: > > I have a mirror at work (Juniper Networks) and we have had all the > > bits since Tuesday. > > You can't have; the final sparc64-6 packages were just finished > yesterday, at the last second. > > mcl Ah, I meant i386. Didn't think about sparc. Carry on. Josef -- FreeBSD 6.2 | Josef Grosch| You can't expect to wield supreme executive power [EMAIL PROTECTED] | just 'cause some watery tart threw a sword at you! ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Re: Fix for GPE livelock on HPs
On 12/23/-58 20:59, Nate Lawson wrote: > Nate Lawson wrote: >> Volker wrote: >>> On 12/23/-58 20:59, Nate Lawson wrote: I've committed the below patch and want to MFC it to 7.0. To do this, I need people to test this quickly. It probably has no effect in 6.x and probably doesn't apply cleanly there. Please try this patch if you have a laptop and 7.x. If you have -current, just cvsup. I'd like to make sure there is no regression. I'm already aware that it fixes things for some HP users. >>> Nate, >>> >>> can you be a bit specific for a) what GPE is, b) what the problem is, >>> c) what to look for (any test procedures?) and d) which HP laptop >>> models might be affected? >>> >>> I do have an Omnibook vt6200 (P-IV 1.8G) running 6-STABLE and a new HP >>> 6715b (Tur-X2 TL-60) running 7-RC1 (currently installing on this, OS >>> is not yet fully set up). >>> >>> If I knew what to look for, I might test your patches (at least on the >>> 7-RC1 version). >> A GPE is an interrupt of sorts. I'm looking for any bad behavior the >> patch might cause. I'm certain it fixes lockups some HPs had during >> thermal zone events (i.e. fan switching on when it gets hot). Pretty >> much anyone with a laptop that locks up and you suspect acpi should test >> it. And anyone who is willing to test it on another brand laptop to be >> sure the patch doesn't break anything more would be welcome. >> >> You should be able to do "sysctl hw.acpi" and see the temperature and >> "apm" to see battery status without any new problems after applying the >> patch. > > I've added a patch for 6-stable also (attached). Please test if you > have a laptop and 6.x. See -current for the 7.x patch if that's > relevant to you. > > -Nate > Nate, I'm sorry, your patch applies cleanly but does not compile on 6-STABLE (csup'ed today, applied patch defer_gpe_6x.diff posted on 2008-01-15). ===> acpi/acpi (all) cc -O2 -fno-strict-aliasing -pipe -Werror -D_KERNEL -DKLD_MODULE -nostdinc -I- -I/usr/src/sys/modules/acpi/acpi/../../../contrib/dev/acpica -DHAVE_KERNEL_OPTIO N_HEADERS -include /usr/obj/usr/src/sys/CESAR/opt_global.h -I. -I@ -I@/contrib/a ltq -I@/../include -finline-limit=8000 -fno-common -g -I/usr/obj/usr/src/sys/CES AR -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mn o-sse -mno-sse2 -ffreestanding -Wall -Wredundant-decls -Wnested-externs -Wstrict -prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat -extensions -std=c99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uniniti alized -c /usr/src/sys/modules/acpi/acpi/../../../contrib/dev/acpica/evgpe.c /usr/src/sys/modules/acpi/acpi/../../../contrib/dev/acpica/evgpe.c: In function `AcpiEvAsynchExecuteGpeMethod': /usr/src/sys/modules/acpi/acpi/../../../contrib/dev/acpica/evgpe.c:664: warning: implicit declaration of function `AcpiOsExecute' /usr/src/sys/modules/acpi/acpi/../../../contrib/dev/acpica/evgpe.c:664: warning: nested extern declaration of `AcpiOsExecute' /usr/src/sys/modules/acpi/acpi/../../../contrib/dev/acpica/evgpe.c:664: error: ` OSL_NOTIFY_HANDLER' undeclared (first use in this function) /usr/src/sys/modules/acpi/acpi/../../../contrib/dev/acpica/evgpe.c:664: error: ( Each undeclared identifier is reported only once /usr/src/sys/modules/acpi/acpi/../../../contrib/dev/acpica/evgpe.c:664: error: for each function it appears in.) *** Error code 1 Stop in /usr/src/sys/modules/acpi/acpi. BTW, reading the source code changes and your commit comments, I'm pretty sure I've seen those ACPI related problems on my HP Omnibook vt6200 using 6-STABLE. Sometimes the tz0 temperature values have been nailed to a fixed value, sometimes the system went too hot (with or without the fan running), sometimes it was just freezing and no way out to revitalize the notebook. I haven't reported this before because something like "my system freezes w/o message" or "the system does stupid things but I don't have an error message" is most likely not the kind of report to get a useful reply for. If you've got another patch for a 6-STABLE target, I'll be happy to test. Thanks! Volker ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: panic: vm_fault: fault on nofualt entry, addr: 81423000
> MADT is the ACPI table that enumerates APICs. Do you have the offset of > madt_probe()? I am sujre I can get it for you - do I need to do anything special in DDB, or is it just the numbers in the bt that you are after ? I can make this panic very easily and do whatever is necessary to get info out. -pete. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: garbled message from p800-controller
On Thu, Jan 17, 2008 at 10:24:55PM +0100, Claus Guttesen wrote: > da1 at ciss1 bus 0 target 0 lun 0 > dSaM1P:: A ME expa> Fixed Direct Access SCSI-5 device > da1: 135.168MB/s transfers First item in http://jdc.parodius.com/freebsd/common_issues.txt has the threads you're interested in. Someone really needs to look into fixing this permanently, because it keeps coming up on the lists, and will likely do so until fixed. :-) -- | Jeremy Chadwickjdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: kldstat causes kernel to print odd message
On Fri, Jan 18, 2008 at 08:17:40AM +1030, Daniel O'Connor wrote: >On Fri, 18 Jan 2008, John Baldwin wrote: >> amd64 uses link_elf_obj.c, all the other archs use link_elf.c, hence >> the duplication. Then why does amd64 need link_elf.c at all? >I guess one option would be to put #ifdef amd64 around the error message >in link_elf.c. If there's a possibility that multiple ELF linkers could be required in the future, a cleaner option might be to make link_elf_error() just cache the error message and only report it after all possible linkers have refused to load the file. -- Peter Jeremy Please excuse any delays as the result of my ISP's inability to implement an MTA that is either RFC2821-compliant or matches their claimed behaviour. pgpuXyOTwM5Ie.pgp Description: PGP signature
Re: kldstat causes kernel to print odd message
On Fri, 18 Jan 2008, Peter Jeremy wrote: > On Fri, Jan 18, 2008 at 08:17:40AM +1030, Daniel O'Connor wrote: > >On Fri, 18 Jan 2008, John Baldwin wrote: > >> amd64 uses link_elf_obj.c, all the other archs use link_elf.c, > >> hence the duplication. > > Then why does amd64 need link_elf.c at all? I wonder if it's because you can't put !amd64 in sys/conf/files :) (so you'd have to put it in every platform specific files instead) > >I guess one option would be to put #ifdef amd64 around the error > > message in link_elf.c. > > If there's a possibility that multiple ELF linkers could be required > in the future, a cleaner option might be to make link_elf_error() > just cache the error message and only report it after all possible > linkers have refused to load the file. That would be the Right Way(tm).. probably just #ifndef amd64'ing link_elf.c will be easier :) One thing that gets me is why I get this problem but noone else seems to.. -- 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 signature.asc Description: This is a digitally signed message part.
