Re: 8.0-Beta installation problem -- Unable to find /dev/ad0s1b
Hi! > I had the same problem with beta4: > > http://lists.freebsd.org/pipermail/freebsd-current/2009-September/011470.html > > and I tried this fix, and it did not solve the problem. > > It might be related with the number of slices and partitions one > is creating ? I'll try this again today. Tested it, no, it does not solve the problem. Is there anything I can do to debug this ? I think I can provide remote console access if necessary. I'll try the LiveCD, too. -- p...@opsec.eu+49 171 310137211 years to go ! ___ 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"
Re: 8.0-Beta installation problem -- Unable to find /dev/ad0s1b
dd 1m zero on the drive and rerun the 8.0Beta4 DVD. Created two slices S1 and S2, and did auto labling (unix partiton) on S1, hit W, the problem persists. Boot system with freeBSD 6.4, and 6.4 sees two slices (MBR partitions) S1 and S2, but no any Unix partition (ad0s1a, ad0s1b etc) on S1. Boot back to 8.0-Beta4, it still sees not Slice created. At this point, it is obviously that 8.0 looks in a wrong MBR location -- 8.0 created slices can be seen by 6.4 but not 8.0 itself. --- On Mon, 9/14/09, Thierry Thomas wrote: > From: Thierry Thomas > Subject: Re: 8.0-Beta installation problem -- Unable to find /dev/ad0s1b > To: "Jin Guojun" > Cc: b...@freebsd.org, freebsd-stable@freebsd.org, curr...@freebsd.org > Date: Monday, September 14, 2009, 10:06 PM > Le Lun 14 sep 09 à 23:08:53 +0200, > Jin Guojun > écrivait : > > I do not enve know how to make "dangerously dedicated" > disk, and the > > 8.0 may do this sliently. > > No, I don't think so! But such a problem may arise if your > disk had been > installed as "dangerously dedicated" in a former version. > Unfortunately, > previous versions of sysinstall have created uncorrect > labels, and the > new gpart in 8.0 does not see them. > > In that case, you have to boot kernel.old and wipe out the > bad label. If > you reboot with a 7.2 kernel, can you see your missing > partitions? > -- > Th. Thomas. > ___ 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"
panic: UMA: page_free used with invalid flags 4
Hello, My server was using FreeBSD-7-Stable and performing a mail server. Software I used is postfix 2.6.3 and dovecot 1.2.4. The hardware is IBM blade server HS-21 CPU: dual Intel E5335 @ 2.00GHz MEM: 3G HD: onboard LSI RAID controller with 2 73G SAS HD. (mpt0: ) The system is very stable until last week. After csup the FreeBSD-7-STABLE source to around 2009/09/10, it will halt randomly around every several hours. The error message I saw on console was the following: panic: UMA: page_free used with invalid flags 4 cpuid = 0 Uptime: 3h1m14s Physical memory: 3064MB Dumping 1544MB: 1529 1513 1497 Reading freebsd-stable mailing shows there is some vm related modfication during the first week of Sep. (the panic: vm_phys_paddr_to_vm_page: paddr 0x series) So, I csup my src back to 2009/09/01, the problem disappeared, and system comes back with stable state. Today, I csup my src to latest 7-STABLE (2009/09/15) and problem comes again. It seems the problem is still there and not be solved yet. Would you please help to fix it? Thanks very much. Sincerely, Tim Chen ___ 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"
Re: 8.0-Beta installation problem -- Unable to find /dev/ad0s1b
On Mon, 14 Sep 2009 14:08:53 -0700 (PDT), Jin Guojun
wrote:
> I do not enve know how to make "dangerously dedicated" disk,
> and the 8.0 may do this sliently.
This term refers to a disk where no "DOS primary partition",
i. e. a slice, has been created. Usually, for a disk with
only FreeBSD on it, you first take a disk
/dev/ad0
create a slice
/dev/ad0s1
and put partitions into it (or just one partition), like
/dev/ad0s1a = /
/dev/ad0s1b = swap
/dev/ad0s1d = /tmo
/dev/ad0s1e = /var
/dev/ad0s1f = /usr
/dev/ad0s1g = /home
or something similar. In "dangerously dedicated" mode, you
omit the slice creation and create the partitions on the
disk device /dev/ad0, so you end up with
/dev/ad0a = /
/dev/ad0b = swap
/dev/ad0d = /tmo
/dev/ad0e = /var
/dev/ad0f = /usr
/dev/ad0g = /home
Using such mode is common for data disks, but not for disks
you boot from.
> ad0 had three DOS partitions (slices),
> S1 for DOS
> S2 for FreeBSD 7.2
> S3 for another FreeBSD
>
> When boot to 8.0-Beta{3, 4}, 8.0 sees not partition, which means
> 8.0 looked at a wrong location for partition table.
What does the "fdisk" command report?
> After did partition (slices S1 for FreebSD and S2 for nothing) and
> Label (Unix partitions, failed to find device node /dev/ad0s1b in /dev),
> content of 7.2 is gone.
Seems to be correct up to here; /dev/ad0s1b refers to the swap
partition.
> But, the original partitions are still in the MBR (S1 for DOS, and
> S2 and S3 for FreeBSD).
So an update of the MBR hasn't taken place?
--
Polytropon
Magdeburg, Germany
Happy FreeBSD user since 4.0
Andra moi ennepe, Mousa, ...
___
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"
Re: cxgb LOR
A lot of these LORs were fixed in cxgb in FreeBSD 8. You can look at cxgb_main.c in 8 for details. I'll also try and figure out if those changes are easily MFC'able. Regards, Navdeep On Mon, Sep 14, 2009 at 2:29 PM, Matthew Fleming wrote: > We got a cxgb LOR report of: > > 1st 0xff8001e37be0 vlan_global (vlan_global) @ > /build/mnt/src/sys/modules/if_vlan/../../net/if_vlan.c:1310 > 2nd 0xff80010892f0 cxgb port lock (cxgb port lock) @ > /build/mnt/src/sys/modules/cxgb/../../dev/cxgb/cxgb_main.c:1956 > KDB: stack backtrace: > db_trace_self_wrapper() at db_trace_self_wrapper+0x2a > witness_checkorder() at witness_checkorder+0x9e2 > _sx_xlock() at _sx_xlock+0x55 > cxgb_ioctl() at cxgb_ioctl+0x1e8 > vlan_ioctl() at vlan_ioctl+0x359 > ifhwioctl() at ifhwioctl+0xb1 > ifioctl() at ifioctl+0xb1 > kern_ioctl() at kern_ioctl+0xa3 > ioctl() at ioctl+0xf1 > freebsd32_ioctl() at freebsd32_ioctl+0x13e > isi_syscall() at isi_syscall+0x94 > ia32_syscall() at ia32_syscall+0x1a3 > Xint0x80_syscall() at Xint0x80_syscall+0x60 > --- syscall (54, FreeBSD ELF32, freebsd32_ioctl), rip = 0x2868db1b, rsp > = 0xd4bc, rbp = 0xda38 --- > > > So we tried changing cxgb to not USE_SX. This resulted in a different > LOR: > > lock order reversal: (sleepable after non-sleepable) > 1st 0xff8000f9d508 cxgb controller lock 0 (cxgb controller lock 0) > @ > /build/mnt/src/sys/modules/cxgb/cxgb/../../../dev/cxgb/cxgb_main.c:1889 > 2nd 0x806064e0 ACPI root bus (ACPI root bus) @ > /build/mnt/src/sys/dev/acpica/acpi.c:1040 > KDB: stack backtrace: > [8018e9fa] db_trace_self_wrapper+0x2a > [80298e89] witness_checkorder+0x719 > [8025bf75] _sx_xlock+0x55 > [8019678a] acpi_alloc_resource+0x9a > [80281714] resource_list_alloc+0x184 > [801d9f98] pci_alloc_resource+0x158 > [802814b9] bus_alloc_resource+0x89 > [81804201] cxgb_setup_interrupts+0x51 > [81807f33] cxgb_up+0xa3 > [818083c0] cxgb_init_locked+0x1b0 > [81808539] cxgb_init+0x39 > [81808758] cxgb_ioctl+0x1f8 > [8031e9e1] ifhwioctl+0xb1 > [8031f720] ifioctl+0xb0 > [8029a873] kern_ioctl+0xa3 > [8029aad1] ioctl+0xf1 > [8041eb93] freebsd32_ioctl+0xb3 > [8025d963] isi_syscall+0x83 > [8041de63] ia32_syscall+0x1a3 > [803efc60] Xint0x80_syscall+0x60 > --- syscall (54, FreeBSD ELF32, freebsd32_ioctl), rip = 0x2826ea67, rsp > = 0xd8ac, rbp = 0xd928 --- > > (we modified cxgb_ioctl to call cxgb_init because otherwise the cxgb > interface would require an ifconfig up before it detected a link, which > was different behaviour from the em driver. Since the locks in question > are acquired inside cxgb_init() I don't think the rest of the stack is > relevant, but network stack isn't my area of expertise). > > So it seems that with cxgb we're damned if we do, damned if we don't. > Any advice on which LOR is "worse" or if one is harmless, or how to make > it go away? > > Note also that if cxgb uses a mtx then it will do malloc while holding > the mtx in this stack: > > [803cc58a] uma_zalloc_arg+0x2da > [80241ef9] malloc+0x89 > [8023115f] intr_event_add_handler+0x5f > [803f26d2] intr_add_handler+0x72 > [801dc171] pci_setup_intr+0x41 > [801dc171] pci_setup_intr+0x41 > [802807e6] bus_setup_intr+0x96 > [8180423c] cxgb_setup_interrupts+0x8c > [81807f33] cxgb_up+0xa3 > [818083c0] cxgb_init_locked+0x1b0 > [81808539] cxgb_init+0x39 > > Thanks, > matthew > ___ > 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" > ___ 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"
Re: 8.0-Beta installation problem -- Unable to find /dev/ad0s1b
Le Lun 14 sep 09 à 23:08:53 +0200, Jin Guojun écrivait : > I do not enve know how to make "dangerously dedicated" disk, and the > 8.0 may do this sliently. No, I don't think so! But such a problem may arise if your disk had been installed as "dangerously dedicated" in a former version. Unfortunately, previous versions of sysinstall have created uncorrect labels, and the new gpart in 8.0 does not see them. In that case, you have to boot kernel.old and wipe out the bad label. If you reboot with a 7.2 kernel, can you see your missing partitions? -- Th. Thomas. ___ 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"
cxgb LOR
We got a cxgb LOR report of: 1st 0xff8001e37be0 vlan_global (vlan_global) @ /build/mnt/src/sys/modules/if_vlan/../../net/if_vlan.c:1310 2nd 0xff80010892f0 cxgb port lock (cxgb port lock) @ /build/mnt/src/sys/modules/cxgb/../../dev/cxgb/cxgb_main.c:1956 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2a witness_checkorder() at witness_checkorder+0x9e2 _sx_xlock() at _sx_xlock+0x55 cxgb_ioctl() at cxgb_ioctl+0x1e8 vlan_ioctl() at vlan_ioctl+0x359 ifhwioctl() at ifhwioctl+0xb1 ifioctl() at ifioctl+0xb1 kern_ioctl() at kern_ioctl+0xa3 ioctl() at ioctl+0xf1 freebsd32_ioctl() at freebsd32_ioctl+0x13e isi_syscall() at isi_syscall+0x94 ia32_syscall() at ia32_syscall+0x1a3 Xint0x80_syscall() at Xint0x80_syscall+0x60 --- syscall (54, FreeBSD ELF32, freebsd32_ioctl), rip = 0x2868db1b, rsp = 0xd4bc, rbp = 0xda38 --- So we tried changing cxgb to not USE_SX. This resulted in a different LOR: lock order reversal: (sleepable after non-sleepable) 1st 0xff8000f9d508 cxgb controller lock 0 (cxgb controller lock 0) @ /build/mnt/src/sys/modules/cxgb/cxgb/../../../dev/cxgb/cxgb_main.c:1889 2nd 0x806064e0 ACPI root bus (ACPI root bus) @ /build/mnt/src/sys/dev/acpica/acpi.c:1040 KDB: stack backtrace: [8018e9fa] db_trace_self_wrapper+0x2a [80298e89] witness_checkorder+0x719 [8025bf75] _sx_xlock+0x55 [8019678a] acpi_alloc_resource+0x9a [80281714] resource_list_alloc+0x184 [801d9f98] pci_alloc_resource+0x158 [802814b9] bus_alloc_resource+0x89 [81804201] cxgb_setup_interrupts+0x51 [81807f33] cxgb_up+0xa3 [818083c0] cxgb_init_locked+0x1b0 [81808539] cxgb_init+0x39 [81808758] cxgb_ioctl+0x1f8 [8031e9e1] ifhwioctl+0xb1 [8031f720] ifioctl+0xb0 [8029a873] kern_ioctl+0xa3 [8029aad1] ioctl+0xf1 [8041eb93] freebsd32_ioctl+0xb3 [8025d963] isi_syscall+0x83 [8041de63] ia32_syscall+0x1a3 [803efc60] Xint0x80_syscall+0x60 --- syscall (54, FreeBSD ELF32, freebsd32_ioctl), rip = 0x2826ea67, rsp = 0xd8ac, rbp = 0xd928 --- (we modified cxgb_ioctl to call cxgb_init because otherwise the cxgb interface would require an ifconfig up before it detected a link, which was different behaviour from the em driver. Since the locks in question are acquired inside cxgb_init() I don't think the rest of the stack is relevant, but network stack isn't my area of expertise). So it seems that with cxgb we're damned if we do, damned if we don't. Any advice on which LOR is "worse" or if one is harmless, or how to make it go away? Note also that if cxgb uses a mtx then it will do malloc while holding the mtx in this stack: [803cc58a] uma_zalloc_arg+0x2da [80241ef9] malloc+0x89 [8023115f] intr_event_add_handler+0x5f [803f26d2] intr_add_handler+0x72 [801dc171] pci_setup_intr+0x41 [801dc171] pci_setup_intr+0x41 [802807e6] bus_setup_intr+0x96 [8180423c] cxgb_setup_interrupts+0x8c [81807f33] cxgb_up+0xa3 [818083c0] cxgb_init_locked+0x1b0 [81808539] cxgb_init+0x39 Thanks, matthew ___ 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"
Re: 8.0-Beta installation problem -- Unable to find /dev/ad0s1b
I do not enve know how to make "dangerously dedicated" disk, and the 8.0 may do
this sliently.
ad0 had three DOS partitions (slices),
S1 for DOS
S2 for FreeBSD 7.2
S3 for another FreeBSD
When boot to 8.0-Beta{3, 4}, 8.0 sees not partition, which means 8.0 looked at
a wrong location for partition table.
After did partition (slices S1 for FreebSD and S2 for nothing) and
Label (Unix partitions, failed to find device node /dev/ad0s1b in /dev),
content of 7.2 is gone.
But, the original partitions are still in the MBR (S1 for DOS, and S2 and S3
for FreeBSD).
--- On Mon, 9/14/09, Thierry Thomas wrote:
> From: Thierry Thomas
> Subject: Re: 8.0-Beta installation problem -- Unable to find /dev/ad0s1b
> To: "Jin Guojun"
> Cc: b...@freebsd.org, freebsd-stable@freebsd.org, curr...@freebsd.org
> Date: Monday, September 14, 2009, 6:45 PM
> Le Lun 14 sep 09 à 18:56:38 +0200,
> Jin Guojun
> écrivait :
> > It seems that disklabel is the problem spot.
>
> Hello,
>
> I encountered such a problem too; was your disk ad0
> installed as
> "dangerously dedicated"?
>
> Regards,
> --
> Th. Thomas.
>
___
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"
Re: 8.0-Beta installation problem -- Unable to find /dev/ad0s1b
Le Lun 14 sep 09 à 18:56:38 +0200, Jin Guojun écrivait : > It seems that disklabel is the problem spot. Hello, I encountered such a problem too; was your disk ad0 installed as "dangerously dedicated"? Regards, -- Th. Thomas. ___ 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"
Re: 8.0-Beta installation problem -- Unable to find /dev/ad0s1b
It seems that disklabel is the problem spot. Use 8.0 Partition menu to allocate 2 slices (partitions) 20GB for S1 and rest for S2, then install 8.0-Beta4 on S1. W command in slice (Partition) menu succeed with bootloader manager installing option (Choose FreeBSD), but W command in Label menu had the same error -- Unable to find device node ... After quite installationm and restart the system, the bootloader is still show old partitions (S1 DOS, S2/S3 7.2). Boot 8.0-Beta4 DVD again, and Partition menu shows no partition at all (no slice allocated). This indicates that disklabel did not correctly write disk partition information on to the dirve. --- On Mon, 9/14/09, Robert Huff wrote: > From: Robert Huff > Subject: Re: 8.0-Beta installation problem -- Unable to find /dev/ad0s1b > To: "Jin Guojun" > Cc: "Robert Huff" , curr...@freebsd.org, > b...@freebsd.org, freebsd-stable@freebsd.org > Date: Monday, September 14, 2009, 3:49 AM > > Jin Guojun writes: > > > Did not find anything from current, but found > the same problem > > has been reported in earlier releases in those > archives, and the > > latest was May 2009: > > Try this (for the fix) : > > http://lists.freebsd.org/pipermail/freebsd-current/2009-September/011254.html > > > > > Robert Huff > > ___ 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"
Linux/KDE and NFS locking on 7-stable
Hi all, I upgraded a FreeBSD fileserver last week from 7.0-stable to 7.2-stable and experience some weird problems now with Linux NFS clients. The Linux Clients mount their home directories via nfs. I usually use "nolock" on the client side, because file locking was always troublesome in the past. On the Clients the users run kde 3.5 or 4.2. After the update of the server kde 3.5 quit starting up (after logging in with kdm) on the spalsh screen and comes up with some kind of I/O error when writing to the home dir. At the same time the server complains about kernel: NLM: failed to contact remote rpcbind, stat = 5, port = 28416 Any other window manager (xfce, icewm, mwm, twm) seems to work fine. Playing around with locking, udp/tcp, rebooting some times then somehow magically made it work with kde 3.5 again (although I am using the same mount options in the and as I used before): mclane:/tank/home/gco /tank/home/ghf nfs nfsvers=3,rw,nolock,nordirplus 0 0 Turning locking on definitely does not work (tried it three times). rcp.lockd and rpc.statd are running on the server side, no further tuning done there. KDE 4.2 seems to have better, I have been able to get it working with locking turned on (but it refused to work without locking with the same errors as described above for kde 3.5). I find the whole situation a bit unattractive. Can anybody here give me a hint which combination of mount options should work for a FreeBSD Server running 7.2-stable and Linux clients running 2.6.29 and KDE3/4? I am not that much into performance here, I want a stable working solution. And why, after all, is KDE so picky about locking and nfs homedirs anyway? All other environments appear not to show these problems. cu Gerrit ___ 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"
Re: Kernel panic in ulpt
On Friday 11 September 2009 12:18:39 pm Alban Hertroys wrote: > Hello, > > I just got a kernel panic on a FreeBSD 7.2 STABLE after a print job > finished on ulpt. The kgdb output (ran in script) is attached. I'll > keep the vmcore around in case anyone needs more info. Shout if you > need more info. In ulptclose() in sys/dev/usb/ulpt.c try changing the callout_stop() to a callout_drain(). Have you been able to reproduce this? -- 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"
Re: How to enable CPU turbo mode on FreeBSD?
On Friday 11 September 2009 11:46:13 am Pierre-Luc Drouin wrote: > John Baldwin wrote: > > On Thursday 10 September 2009 8:57:32 pm Pierre-Luc Drouin wrote: > > > >> Hi, > >> > >> I have an overclocked i7 920 CPU for which I have enabled Turbo Mode in > >> the BIOS (21x multiplier). The base clock is set at 190 MHz, so the CPU > >> frequency with Turbo mode activated should be 3990 MHz. However the > >> maximum value FreeBSD amd64 shows for the CPU frequency in dmesg and > >> sysctl is 3790 MHz. How can I enable the Turbo Mode? > >> > >> CPU: Intel(R) Core(TM) i7 CPU 920 @ 2.67GHz (3790.52-MHz > >> K8-class CPU) > >> > >> machdep.acpi_timer_freq: 3579545 > >> machdep.tsc_freq: 3790522507 > >> machdep.i8254_freq: 1193182 > >> dev.cpu.0.freq: 349 > >> dev.cpu.0.freq_levels: 2793/13 2443/113750 2094/97500 1745/81250 > >> 1396/65000 1047/48750 698/32500 349/16250 > >> > > > > You have to enable C2/C3 sleep states (possibly in your BIOS). However, > > FreeBD doesn't currently handle this but so well since that will probably > > turn off the local APIC timer interrupt when the CPU is idle causing FreeBSD > > to miss clock interrupts. > > > > > Sorry I am not sure exactly what you are referring to. Do you mean that > I need to enable C2/C3 states in order to have the correct max CPU freq > value displayed at boot time/in sysctl, or you mean that I need these > states in order to be able to use the Turbo Mode at all? Right now in > the BIOS I had the following features disabled to test the overclocking > (I was following what is recommended to do for Windows users to run > stress tests): > > -Intel SpeedStep: Use this function to enable the Intel SpeedStep > technology (EIST) > -CxE Function: This function allows you to select the lowest C state > supported according as CPU and MB. The options are Auto, Disabled, C1, > C1E, C3 and C6 You need to have C2/C3 enabled for it to work at all, at least on Nehalem processors. -- 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"
Re: 7.2-release/amd64: panic, spin lock held too long
On Mon, Sep 14, 2009 at 3:43 PM, Attilio Rao wrote: > 2009/7/23 C. C. Tang : >> Attilio Rao wrote: >>> >>> 2009/7/22 C. C. Tang : > > Could that one (on i386) be related? > http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/134584 > I have no idea about it but I can tell the difference... My machine panic randomly rather than on shutdown and I remembered that it failed to write core dump. It also failed to reboot automatically.. >>> >>> Is your problem on -CURRENT and amd64? >>> At some point there has been a problem with PAT support (and >>> tlb_shootdowns() could lead to a livelock hanging forever, leading to >>> such a bug) but I expect it is fixed now. >>> Can you try with a fresh new -CURRENT if any? >> >> My problem is on i386 version of 7.2-RELEASE-p2 on Intel Atom 330 CPU. >> And my system just panic randomly with "spin lock held too long". >> It didn't panic at reboot or shutdown so I think it the problem is somewhat >> different from that mentioned by Barbara's PR? >> >> Anyway I disabled powerd and it seems become stable now. >> >> And I am sorry that my system has been put into service so it would be hard >> for me to switch to -CURRENT... :( > > Can you re-enable powerd and try the attached patch?: > http://www.freebsd.org/~attilio/sched_ule.diff > > The patch is against STABLE_7, but I think HEAD has the same bug. > Please try it and report to me. > > Attilio Sadly I can't test this, I had to put the machine into production using another OS. I hope the patch fixes the issue, so I can at some point evaluate using FreeBSD on this hardware again. - Dan ___ 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"
Re: 7.2-release/amd64: panic, spin lock held too long
2009/7/23 C. C. Tang : > Attilio Rao wrote: >> >> 2009/7/22 C. C. Tang : Could that one (on i386) be related? http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/134584 >>> I have no idea about it but I can tell the difference... >>> My machine panic randomly rather than on shutdown and I remembered that >>> it >>> failed to write core dump. It also failed to reboot automatically.. >> >> Is your problem on -CURRENT and amd64? >> At some point there has been a problem with PAT support (and >> tlb_shootdowns() could lead to a livelock hanging forever, leading to >> such a bug) but I expect it is fixed now. >> Can you try with a fresh new -CURRENT if any? > > My problem is on i386 version of 7.2-RELEASE-p2 on Intel Atom 330 CPU. > And my system just panic randomly with "spin lock held too long". > It didn't panic at reboot or shutdown so I think it the problem is somewhat > different from that mentioned by Barbara's PR? > > Anyway I disabled powerd and it seems become stable now. > > And I am sorry that my system has been put into service so it would be hard > for me to switch to -CURRENT... :( Can you re-enable powerd and try the attached patch?: http://www.freebsd.org/~attilio/sched_ule.diff The patch is against STABLE_7, but I think HEAD has the same bug. Please try it and report to me. Attilio -- Peace can only be achieved by understanding - A. Einstein ___ 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"
Re: FreeBSD 8.0-BETA4 IBM ServerRaid 8k issues
George Mamalakis wrote: Artis, and the rest of the guys, thank you all for your answers. Ivan, I was thinking of using one of the techniques you mention (create two volumes, install fbsd on one of them, and use GTP on the second drive), but I was wondering if there would be any "incompatibility" issues with tools like df, etc. No, once you create a parition of large size, the system will "just work". ___ 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"
