/outb) and SMPng
locking. If someone is using this driver and is willing to test fixes for
it, then it can be updated. If there isn't anyone who is using this driver
and willing to test fixes, then it will be removed from the tree at some
point in the future (say a month or two).
-
eight patch. It
has already been tested by the folks working on Wine, but I would like a bit
more widespread testing before I commit it. Please test this patch and let
me know if anything breaks. Note that this patch is only for i386.
http://www.FreeBSD.org/~jhb/patches/sig_eva.patch
--
uspect lsusb is
a Linux specific command, and, indeed, the portions of HPLIP's web-site
dealing with this aspect make clear references to Linux's method of
handling USB device notes.
I am at my wits end. I have tried everything I could
On Friday 13 July 2007 02:08:59 pm Volker wrote:
> On 07/11/07 20:42, John Baldwin wrote:
> > This patch attempts to remove a gross hack with a slightly less gross hack
> > in
> > order to avoid clobbering data in signal info that Wine needs. In 7 this
> > was
>
very much for your help; I'll give the list
a post when I try this.
--Thank you.
John
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
//wiki.freebsd.org/Wine,
and
> everything builds fine, and I'm getting alot further with the tests, but its
> failing at the rebar test ... I've posted to [EMAIL PROTECTED] with
my
> results on this, as it seems to be the Wine side, not FreeBSD ...
>
> John, I've
IRQ 18 when ahd0 tried to probe and ahd0 got
interrupt timeouts. This indicates that ahd0 really lives on IRQ 18, not IRQ
30. Your BIOS is likely busted since ACPI hardcodes these sort of IRQs.
You can override the BIOS by doing:
set hw.pci5.2.INTA.irq=18
in the loader (or adding a line to loader.c
enabled.
> >
> > I think that is OK, right?
> >
>
> Yes, that is fine. Other existing debugging options also break ABI when
> enabled, so it's OK.
Well, MUTEX_PROFILING does and LOCK_PROFILING is the same thing. This option
is a known "special case" that breaks the ABI and people using it should
already be aware of that. Other debugging options (INVARIANTS, WITNESS,
etc.) do not affect the ABI.
--
John Baldwin
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
On Wednesday 24 October 2007 09:49:06 am Guy Helmer wrote:
> John Baldwin wrote:
> > On Tuesday 23 January 2007 01:17:57 pm Guy Helmer wrote:
> >
> >> Jack Vogel wrote:
> >>
> >>> On 1/23/07, Guy Helmer <[EMAIL PROTECTED]> wrote:
> &
On Wednesday 24 October 2007 03:44:52 pm Kris Kennaway wrote:
> John Baldwin wrote:
> > On Sunday 21 October 2007 04:56:30 am Kris Kennaway wrote:
> >> Alfred Perlstein wrote:
> >>> * Robert Watson <[EMAIL PROTECTED]> [071020 10:21] wrote:
> >&g
e some time during the day.
I'm not sure that it is msdosfs' fault. Last night I also corrupted my
FAT based USB memory stick. But I used mtools and did not mount it. That
was on 8-current though. I have not looked into it because there are
other higher priority stuff also not workin
00:15:17:19:59:e4
> em0: [FAST]
>
> It appears that em0 still generates interrupts on irq16, even though it
> should be using MSI.
This was due to a bug with rman_set_rid() not getting used in 6-stable that
broke the most recent MSI MFC. The rman thing
gt; > When the rebuild has finished you may find that the BIOS doesn't
> > realize the array has been rebuilt, but that may not matter (much).
> >
> After rebuilding the bios shows 'Normal' status. It seems that the
> ata-raid driver can't detect when the array need rebuilding.
>
> Thanks for your help
The ata-raid driver does not automatically start a rebuild, you have to kick
if off by hand.
--
John Baldwin
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
quire bounce buffering if your
hardware only supports 32-bit physical addresses). The fix is to use
the bus_dma abstraction in the driver instead of directly using vtophys()
and a driver needs that fix for both PAE and amd64. amr(4) should work
fine with both PAE and amd64 with > 4GB of RAM.
--
Joh
27;hw.pci.enable_msi=1' in the loader to enable it.
--
John Baldwin
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
seconds ....
You have a busted mp table. The mp table isn't used if ACPI is present,
so perhaps ACPI is disabled in the BIOS?
--
John Baldwin
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
isabled
> interrupt storm detected on "irq11:"; throttling interrupt source
> interrupt storm detected on "irq11:"; throttling interrupt source
> interrupt storm detected on "irq11:"; throttling interrupt source
Probably you have a misrouted interrupt and som
this case the first problem (gnu screen)
> >> does not deserve any attention because it is related to the ptmx clonig.
> >> My goal is to find a way to increase the number os pseudo terminal. the
> >> traditional 256 pty is not sufficient for my needs. Is there any way to
.conf. This is normal. If you got a warning, then on shutdown every rc.d
script that is disabled would whine. Simiarly on boot since all rc.d scripts
are started on boot.
--
John Baldwin
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
ified is probably a bad
> idea -- I'll change the default freebsd-update.conf to deal with this.
Considering that /etc/pf.conf is a file that users edit to configure pf(4),
removing it out from under them is probably a very bad idea.
--
John Baldwin
___
Quoting "Chris H." <[EMAIL PROTECTED]>:
Quoting "Chris H." <[EMAIL PROTECTED]>:
Hello,
I seem to remember a similar question being asked in the past. But never
---8<---snip---8<---
I had originally intended to create a raid mirror on the whole lot of HD's
during the install process. But I wa
I'm not sure I remember everything from earlier in this thread so I
don't know if it's relevant, BUT you can't boot from a gstripe volume
(or from a gconcat one AFAIK). Inferring from your fstab example below
it doesn't sound like you intend to but I just wanted t
Quoting "Chris H." <[EMAIL PROTECTED]>:
Quoting John Nielsen <[EMAIL PROTECTED]>:
I'm not sure I remember everything from earlier in this thread so I
don't know if it's relevant, BUT you can't boot from a gstripe
volume (or from a gconcat one AFAIK)
Quoting "Chris H." <[EMAIL PROTECTED]>:
If you want specific advice for a specific scenario you can probably
get it, but you'll have to supply some additional details. For
instance I'm still not sure if this is a new install or an upgrade
Both:
I was wondering why gmirror wasn't an option duri
an - may it be needed - be used as a
> testbase.
Hmm, probably /etc/rc.d/mixer is overriding the tunables as it is restoring the
settings
to those from the previous boot. You can disable the mixer script perhaps.
--
John Baldwin
___
freebsd-stabl
On Monday 07 January 2008 08:32:49 am Jouke Witteveen wrote:
> On Jan 7, 2008 7:30 AM, John Baldwin <[EMAIL PROTECTED]> wrote:
> >
> > On Wednesday 02 January 2008 08:35:40 am Jouke Witteveen wrote:
> > > Hello,
> > >
> > > I'm running FreeBSD 7
er to not release the bus (and thus remove its interrupt handler) for
every char but to keep the bus while /dev/lpt0 is open (which would be all
the time with lpd running).
--
John Baldwin
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
On Tuesday 08 January 2008 10:08:05 am Scott Long wrote:
> John Baldwin wrote:
> > On Monday 07 January 2008 10:08:57 pm Adrian Wontroba wrote:
> >> I've recently switched some of my home systems to RELENG7.
> >>
> >> All seemed fairly well until I tried pr
On Tuesday 08 January 2008 10:32:56 am John Baldwin wrote:
> On Tuesday 08 January 2008 10:08:05 am Scott Long wrote:
> > John Baldwin wrote:
> > > On Monday 07 January 2008 10:08:57 pm Adrian Wontroba wrote:
> > >> I've recently switched some of my home sy
>
> *: 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.
--
John Baldwin
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
posed to prevent
this because all the pages in the cache are for the file (vm object) we
are working on. Stephan (ups@) says this is fixed in 7. The tell-tale
sign that we see is pagedaemon starts chewing up lots of CPU as the kernel
tries to realign the page queues a
On Tuesday 15 January 2008 10:25:14 am Vivek Khera wrote:
>
> 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.
&
rack down the problem.
--
John Baldwin
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
On Wednesday 16 January 2008 09:31:55 am John Baldwin wrote:
> On Tuesday 15 January 2008 06:54:53 pm Norberto Meijome wrote:
> > I have crash dumps, but unfortunately, i wiped the kernel.debug after
> > starting a full clean rebuild of kernel + world for today's changes.
>
now 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
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 deb
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 enco
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@f
x%jx\n",
(uintmax_t)madt_physaddr);
+ if (madt_length > MAXDUMPPGS * PAGE_SIZE) {
+ printf("MADT: Table is too large, ignoring\n");
+ return (ENXIO);
+ }
/*
* Verify that we can map the full table and
t you are after ?
> I can make this panic very easily and do whatever is necessary to
> get info out.
Just the stack trace offsets.
--
John Baldwin
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stab
On Friday 18 January 2008 12:57:54 am 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 duplicatio
On Friday 18 January 2008 05:30:06 am Parv wrote:
> (Dropped Vivek K from recipient list; edited the URLs in my previous
> message.)
>
> in message <[EMAIL PROTECTED]>,
> wrote John Baldwin thusly...
> >
> > On Thursday 17 January 2008 06:05:17 am Parv wrote:
>
; instead of 'xsdt->Length' - is that
> code above from 7.0 ?
That doesn't matter actually.
> > You can try adding some printfs to see what the values
of 'rsdp->XsdtPhysicalAddress' and
> > 'xsdt' after the call to madt_map_table() are. Actua
gt; earlier for this branch of the if ?
The patch would be the same, it tried to fix an issue where if the table is
longer than the space we are borrowing to map things we could end up with
problems. I.e. the changes weren't in the RSDT/XSDT path at all,
On Friday 18 January 2008 08:50:31 am John Baldwin wrote:
> On Friday 18 January 2008 05:30:06 am Parv wrote:
> > There was no page fault or trap 12 message when the panic happened.
> > After some of messages are printed (as in dmesg), kdb is entered ...
> >
> > ioapi
ck_object, opts | LOP_EXCLUSIVE,
> file, line);
> 190 curthread->td_locks++;
>
> (kgdb) print *m
> $2 = {lock_object = {lo_name = 0x805bd5d2 "Name Cache",
> lo_type = 0x805bd5d2 "Name Cache", lo_flags = 16973824,
> lo_witness
On Tuesday 24 February 2009 6:11:15 pm John Baldwin wrote:
> Author: jhb
> Date: Tue Feb 24 23:11:15 2009
> New Revision: 189017
> URL: http://svn.freebsd.org/changeset/base/189017
>
> Log:
> Fix some more issues with the real mode BTX.
>
> The old BTX passed th
On Wednesday 25 February 2009 10:02:16 am Guy Helmer wrote:
> John Baldwin wrote:
> > On Tuesday 24 February 2009 4:46:28 pm Guy Helmer wrote:
> >
> >> I think I may have found a clue regarding some of the hangs I'm seeing
> >> on FreeBSD 7.1.
> &g
Error code 1
Gah, sorry for the breakage. I have found the relevant change in HEAD to MFC
and am trying to merge it, but am having some issues with NFS at the moment
that are making it take a while. The two SVN changes I've found so far that
are relevant are 175397 and 178893.
--
Jo
ll you the second with ULE).
Then you will want to see what is running on that CPU. You might want to
check your other coredump and find the td_state member of the thread for
kvoop there as well.
--
John Baldwin
___
freebsd-stable@freebsd.org mai
On Thursday 26 February 2009 5:27:07 pm Guy Helmer wrote:
> John Baldwin wrote:
> > On Thursday 26 February 2009 4:22:15 pm Guy Helmer wrote:
> >
> >> db> show sleepchain 23110
> >> thread 100181 (pid 23110, vmstat) blocked on sx "user map" XLOCK
> processor eflags= resume, IOPL = 0
> current process = 0 ()
> trap number = 12
> panic: page fault
> cpuid = 0
>
> And the message is cycled. The kernel does not boot despite
> vm.pmap.pg_ps_enabled value.
This should now be fixed, apologies for the
On Friday 27 February 2009 11:21:00 am Michael Butler wrote:
> John Baldwin wrote:
> > On Friday 27 February 2009 8:08:30 am Igor Sysoev wrote:
> >
> >> And the message is cycled. The kernel does not boot despite
> >> vm.pmap.pg_ps_enabled value.
> >
> >
On Friday 27 February 2009 11:26:25 am Igor Sysoev wrote:
> On Fri, Feb 27, 2009 at 10:26:15AM -0500, John Baldwin wrote:
>
> > On Friday 27 February 2009 8:08:30 am Igor Sysoev wrote:
> > > Is anyone able to boot kernel with recently merged superpage support ?
> &g
17
20:55:47
+++ //depot/user/jhb/boot/sys/boot/i386/loader/main.c 2009/03/02 17:08:30
@@ -102,7 +102,7 @@
*/
bios_getmem();
-#if defined(LOADER_BZIP2_SUPPORT) || defined(LOADER_FIREWIRE_SUPPORT) ||
defined(LOADER_ZFS_SUPPORT)
+#if defined(LOADER_BZIP2_SUPPORT) || defined(LOADER_FIRE
>
> to /boot/loader.conf, rebooting and see if that fixes the problem. If so,
> you might provide the list with your hardware configuration.
Note that superpages is not on by default in 7 the way it is in 8. BTW, can
you get more details from your actual crash dump? I'm n
, I would report it to Alan. The one earlier report of this
didn't include the detail that it was only off by one page.
--
John Baldwin
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stab
what happened with 6.4 and 7.1. It does create a _lot_ of
noise for later /etc merges. Probably our SVN -> CVS importer could simply
ignore commits that create a new branch to avoid this problem.
--
John Baldwin
___
freebsd-stable@freebsd.org mai
On Sunday 15 March 2009 10:14:12 pm Peter Jeremy wrote:
> On 2009-Mar-12 08:46:50 -0400, John Baldwin wrote:
> >On Thursday 12 March 2009 12:36:46 am Peter Jeremy wrote:
> >> I'm trying to upgrade an 11 month old FreeBSD 7 image in a VMware
> >> 4.5.2 guest to an
d them, so I am as up-to-date as you
> could be.
>
> I suspect recent changes to vm code... perhaps in /usr/src/sys/vm/
> vm_meter.c or vm_page.c ?
>
> The compressed core dump is 41 MB.
When I have seen this panic on machines in the past it was caused by b
d to build on 6.2-R the bge(4) sources checked from later RELENG_6
> just after BCM5722 support (from if_bgereg.h 1.36.2.11/ if_bge.c1.91.2.26)
> in order to backport BCM5722 support into 6.2-R. After some tweaks it
> was built, so..
Can you further narrow down where the regression occurs?
-
check_vnode_write(active_cred, fp->f_cred, vp);
if (error == 0)
#endif
error = VOP_WRITE(vp, uio, ioflag, fp->f_cred);
...
}
Can you check your /sys/kern/vfs_vnops.c and verify that LK_EXCLUSIVE is
present in your vn_write() routine? If so, then perhaps run memtest?
--
Joh
ses
(that is, I wouldn't upload 6.4-RELEASE-p10 to ftp since we don't upload new
release bits for every security advisory we do).
--
John Baldwin
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
On Thursday 19 March 2009 12:02:51 pm Kostik Belousov wrote:
> On Thu, Mar 19, 2009 at 10:01:44AM -0400, John Baldwin wrote:
> > On Thursday 19 March 2009 8:05:34 am Tim Chase wrote:
> > > Hello,
> > >
> > > I have a system that had been running quite well
Well, you need to use GPT, either via gpart(8) or gpt(8). You can then use
gptboot to boot from that volume if desired.
--
John Baldwin
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
ULL, so n - 1 is the correct
fix.
--
John Baldwin
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
On Thursday 09 April 2009 10:32:05 am Danny Braniss wrote:
> > Danny Braniss wrote:
> > >> This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
> > >> --enig90DADA8437A99D893FB775F8
> > >> Content-Type: text/plain; charset=3DUTF-8
> > >> Content-Transfer-Encoding: quoted-printable
6ecfc) at
> /usr/src/sys/kern/kern_sysctl.c:1443
> #11 0xc07f6a85 in syscall (frame=0xe766ed38) at
> /usr/src/sys/i386/i386/trap.c:1090
> #12 0xc07db850 in Xint0x80_syscall ()
at /usr/src/sys/i386/i386/exception.s:255
> #13 0x0033
ymbols from
> /boot/kernel/daemon_saver.ko.symbols...done.
> done.
> Loaded symbols for /boot/kernel/daemon_saver.ko
> #0 doadump () at pcpu.h:195
> 195 __asm __volatile("movq %%gs:0,%0" : "=r" (td));
> (kgdb) list *0x8:0x80424561
> A synt
n.
> Jumping in ddb> shows the next:
>
> 1) first, this is a 8-way web server. No processes on runqueue except one
httpd
> (i.e. ps shows R in its state):
You need to find who owns Giant and what that thread is doing. You can try
using 'show lock Giant' a
On Friday 01 May 2009 12:50:15 pm Alan Amesbury wrote:
> John Baldwin wrote:
>
> > Drop the '0x8:' from this and it will work better. Also, 'bt' output
would be
> > good.
>
> Thanks for the pointer (no pun intended).
>
>
> (kgdb
On Mon, 04 May 2009, 09:26 +0100, John wrote:
> Hi list, hopefully this is the right one and not -questions
Perhaps -hubs would have been a better choice?
> cvsup.uk.freebsd.org appears to have not been serving these last few
> weeks. I get, variously, in my logs:
>
> Parsin
d" is not available.
> ) at /usr/src/sys/kern/sched_ule.c:1944
> 1944cpuid = PCPU_GET(cpuid);
> (kgdb)
Please get a backtrace using 'bt'.
Also, 'l *0xc063d904' may also be useful.
--
John Baldwin
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
both this
and the problem with the Alias() operator.
Jung-uk Kim
on 05/05/2009 19:45 Andriy Gapon said the following:
on 01/05/2009 22:01 John Baldwin said the following:
The trace actually ends here. There is nothing super bad here
but there is a big problem actually in that the idle thre
When it panics, can you please type "bt" (assuming you have the debugger
compiled in) and show the output?
I have this too. I have dump too.
Sorry about that. I merged the fixes to vgapci this morning so this
should be fixed now.
On Monday 04 May 2009 11:41:35 pm pluknet wrote:
> 2009/5/1 John Baldwin :
> > On Thursday 30 April 2009 2:36:34 am pluknet wrote:
> >> Hi folks.
> >>
> >> Today I got a new locking issue.
> >> This is the first time I got it, and it's merely
away all events that happen prior to devd starting up I think.
--
John Baldwin
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
On Thursday 07 May 2009 8:41:44 am Alexander Kriventsov wrote:
> Hi,
> Sorry for my english.
> I have fatal trap on my box.
> Kernel compiled with debug options. System is RELENG_7 amd64 dated
> 2009-04-14.
I think this is fixed in the latest RELENG_7.
-
oring kthread of the mpt(4) driver.
> -8<-
>
> Here are the diff:
>
http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/mpt/mpt_raid.c.diff?r1=1.15;r2=1.15.2.1
>
>
> What can I do now?
Can you get more details on the crash, perhaps a crash dump?
--
John Bal
it appears that only the igb
> > driver that are using MSI/MSIX, unless you have a reason to suspect
> > otherwise?
>
> How do you tell that, about igb? looking at the server I have the igb
> device on, it doesn't seem to say anything about that ...
IRQs > 256 are MSI/MSI-X.
--
John Baldwin
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
to test. The patch has gratuitous style changes I wouldn't
include in a commit though.
--
John Baldwin
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
On Monday 11 May 2009 12:55:22 pm Riccardo Torrini wrote:
> On Mon, May 11, 2009 at 09:53:21AM -0400, John Baldwin wrote:
>
> >> What can I do now?
>
> > Can you get more details on the crash, perhaps a crash dump?
>
> All what you want, but you need to drive me,
On Tuesday 12 May 2009 2:12:27 am pluknet wrote:
> 2009/5/11 John Baldwin :
> > On Monday 04 May 2009 11:41:35 pm pluknet wrote:
> >> 2009/5/1 John Baldwin :
> >> > On Thursday 30 April 2009 2:36:34 am pluknet wrote:
> >> >> Hi folks.
> >> &g
On Tuesday 12 May 2009 11:20:14 am Riccardo Torrini wrote:
> On Mon, May 11, 2009 at 02:07:19PM -0400, John Baldwin wrote:
>
> > Do you have kernel crashdumps enabled and a swap partition?
> > If so, do you happen to have any files in /var/crash?
>
> Yes, but I'm u
On Tuesday 12 May 2009 12:10:25 pm Riccardo Torrini wrote:
> On Tue, May 12, 2009 at 11:44:20AM -0400, John Baldwin wrote:
>
> > If you can get a stack trace, that would be most helpful.
> > My guess is that the recovery thread is holding the mpt lock
> > and callin
's a non-important difference.
>
>18 0 0 0 LL *Giant0xd0a6b140 [swi4: clock sio]
> db> bt 18
Ok, this is a known issue in 6.x. It is fixed in 6.4.
--
John Baldwin
___
freebsd-stable@freebsd.org mailing list
http:/
this a 2 CPU system? If so, both CPUs are actually running something, so
it is not a deadlock per se.
> 99402 www 1 960 163M 29892K CPU1 1 0:03 0.00% httpd
> 13635 88 34 960 92340K 25604K CPU0 0 0:00 0.05% mysqld
--
John Baldwin
__
e lot more
space that way (you might be able to map 2.5GB or so). Moving to amd64 gives
you a 64-bit virtual address space and you will be able to easily mmap()
much, much more than 4GB out of the box.
--
John Baldwin
___
freebsd-stable@free
On Wednesday 13 May 2009 2:40:33 am pluknet wrote:
> 2009/5/13 pluknet :
> > 2009/5/13 John Baldwin :
> >> On Tuesday 12 May 2009 4:59:19 pm pluknet wrote:
> >>> Hi.
> >>>
> >>> From just another box (not from the first two mentioned earlier
On Wednesday 13 May 2009 11:41:22 am pluknet wrote:
> 2009/5/13 John Baldwin :
> > On Wednesday 13 May 2009 2:40:33 am pluknet wrote:
> >> 2009/5/13 pluknet :
> >> > 2009/5/13 John Baldwin :
> >> >> On Tuesday 12 May 2009 4:59:19 pm pluknet wrote:
>
On Wednesday 13 May 2009 12:34:39 pm Marc G. Fournier wrote:
> On Wed, 13 May 2009, John Baldwin wrote:
>
> > On Wednesday 13 May 2009 3:09:33 am Marc G. Fournier wrote:
> >>
> >> Don't know if this helps with anything, but it just hung after 2days
again
>
On Wednesday 13 May 2009 1:44:55 pm Marc G. Fournier wrote:
> On Wed, 13 May 2009, John Baldwin wrote:
>
> > Well, you had a whole lot of page faults and other VM activity, plus 500k
> > syscalls. The 'w' is a count of swapped processes, so basically your box is
>
ame pointer = 0x10:0x36ee7f
> code segment = base 0x0, limit 0xf, type 0x1b
> = DPL 0, pres 1, long 1, def32 0, gran 1
> processor eflags = resume, IOPL = 0
> current process = 26 (irq256: bge0)
> trap number = 12
> p[*CURSOR STOPPED HERE*]
--
John Baldwin
__
fff, type 0x1b
> > = DPL 0, pres 1, def32 1, gran 1
> > processor eflags= interrupt enabled, resume, IOPL = 0
> > current process = 5263 (nessusd)
> > trap number = 12
> > panic: page fault
> > cpuid = 3
>
>
--
John Baldwin
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
On Thursday 14 May 2009 1:10:26 pm Martin wrote:
> Am Thu, 14 May 2009 09:16:40 -0400
> schrieb John Baldwin :
>
> > On Thursday 14 May 2009 7:47:23 am Martin Sugioarto wrote:
> > [...]
> > > kernel trap 12 with interrupts disabled
> > >
> > >
he other chipsets are good about
allocating these resources in their chipinit routines rather than the
per-channel allocate routine. Well, except ata_pci_allocate() is also
busted. *sigh* I can work on a patch for HEAD if you are willing to test.
--
John Baldwin
__
On Friday 15 May 2009 10:57:27 am Martin wrote:
> Am Fri, 15 May 2009 08:15:19 -0400
> schrieb John Baldwin :
>
> Hi John,
>
> > When I have seen this, it has often been due to a hardware failure
> > such as bad RAM.
>
> hmmm... I will check this next week.
On Friday 15 May 2009 11:36:18 am Martin wrote:
>
> Hi John,
>
> one more thing that I noticed. It seems that the netmask passed to the
> procedure rt_maskedcopy is invalid. Cannot dereference the pointer.
>
> I went one frame up and I've looked at the control fl
On Friday 15 May 2009 11:38:00 am Martin wrote:
> Am Fri, 15 May 2009 11:09:20 -0400
> schrieb John Baldwin :
>
> > x/i please. The /i decodes it as an instruction so I can see which
> > registers it was attempting to dereference.
>
> Oh sorry...
>
&
On Sunday 17 May 2009 6:51:19 pm Alexander Motin wrote:
> John Baldwin wrote:
> > Sounds like the ATA driver is allocating the same BAR twice. Hmm, yes, it
> > allocates the resources once for each channel it seems in the ata_ali_sata
> > attachment. Looking in ata-chi
901 - 1000 of 1675 matches
Mail list logo
