Re: 4.8 Alternate system clock has died error
Charles Sprickman wrote:
On Tue, 22 Nov 2005, Uwe Doering wrote:
Charles Sprickman wrote:
[...]
So it certainly looks easy enough for me to change the first two
sections of the diff referenced above, but I'm having issues finding
that last one in cpu_initclocks(). It looks like that section really
has changed quite a bit. (see v.1.206)
Just look for all instances of
writertc(RTC_STATUSB, rtc_statusb);
and put
rtcin(RTC_INTR);
directly behind them (into the next line). There should be three of
them, in 4.8 as well as RELENG_4 and CURRENT.
I found the first two (line 721 and 979) and I see third at line 1064.
One other question, looking at the initial patch
(http://www.freebsd.org/cgi/query-pr.cgi?pr=17800), I see that they
followed a slightly different line:
/* Initialize RTC. */
writertc(RTC_STATUSA, rtc_statusa);
writertc(RTC_STATUSB, RTCSB_24HR); ---
+rtcin(RTC_INTR); /* clear any pending interrupt */
Should I worry about that at all?
No. User supplied patches in PRs aren't necessarily 100% correct. In
this case the PR submitter clears pending interrupts while interrupt
generation is disabled. However, the committer of 1.214 (John Baldwin,
in fact) thought that this is wrong because you have to clear pending
interrupts after interrupt generation has been re-enabled, or else you'd
get a race condition. And I agree with that.
Is there any interest in moving this back to 4-STABLE?
Interest there is, I suppose. Plenty of people still run 4.x. The
question is rather whether there is any committer willing to do the
backport. As far as I can tell, most of them are more focused on
newer branches. Perhaps we need special backporting committers for
legacy branches. Just a thought. ;-)
Yeah, I work on a total of about 32 boxes, all still at either 4.8 or
4.11. Committers have to know C, right? :)
Not only that. In case of kernel issues they also have to have quite a
lot of knowledge and experience in kernel hacking. If you botch a
kernel patch and don't notice in time you'll likely cause quite a lot of
grief for the users.
[...]
If anyone wants to satisfy my curiousity about this whole clock issue,
I'd be grateful. A few questions:
RTC = CMOS clock?
Right.
Does the RTC supply all timing in a system, or just time of day?
Just the latter (once at boot time) and also the RTC interrupt
('stathz'). Perhaps 'profhz' too, if you enable profiling. Can't tell
offhand.
How does this line relate to things? kern.clockrate: { hz = 100, tick =
1, tickadj = 5, profhz = 1024, stathz = 128 }
If the RTC doesn't supply the base timing for things like all the I/O
busses, processor, what does?
There's another clock device, which 'hz' is derived of, for example.
Perhaps one can call it the CPU clock. It drives the CPU, memory, PCI
bus etc. Also, while the system is running it drives the kernel's
time-of-day clock. However, the CPU clock's frequency isn't overly
accurate. That's why the kernel's time-of-day clock usually deviates
pretty much from the wall clock unless you apply some form of continuous
adjustment, for instance NTP.
Uwe
--
Uwe Doering | EscapeBox - Managed On-Demand UNIX Servers
[EMAIL PROTECTED] | http://www.escapebox.net
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: poll()/select()
Welcome, John, thanks for the answer. I'll test today bus_setup_intr() without INTR_FAST flag, but how I remember, this cause to system heavy load for interrupt processing ;( in my case. My handler uses spin mutexes to block inter-interrupting sleep mutexes to block some structures now. I have tried to use swi/taskqueue, but result is a sync degradation level. Can you help with sources briefing in my driver case? Thnx in advance. Best regards, Konstantin Prokazoff Center Of Excellence, S_V_R Ltd., Kyiv HQs, Ukraine Official business-partner DevConnect member of Avaya Inc. Regional development support center of Digium Inc. Tel. +38 044 594 1781, ext. 1038 Fax. +38 044 234 0455 - Original Message - From: John Baldwin [EMAIL PROTECTED] To: freebsd-hackers@freebsd.org Cc: Konstantin Prokazoff [EMAIL PROTECTED] Sent: Monday, November 21, 2005 5:38 PM Subject: Re: poll()/select() On Monday 21 November 2005 08:14 am, Konstantin Prokazoff wrote: Thanks for comment, I think, after kernel inspection, problem (maybe) in preemption. While syscall to poll or select holds sellock, and if another thread (process) tries to syscall or we have taken interrupt (where handler use selrecord/selwakeup too), kernel will deadlock. I have this situation cause to INTR_FAST interrupt handler in device driver for Digium's PCI board, which provides 4 T1/E1 interfaces. Problem 100% repetitive. Another way to avoid such deadlock - provide different kthread/ithreads for select/poll mechanism. You can't call selwakeup() from an INTR_FAST handler. Try removing INTR_FAST and see if it fixes your issue. If you want to use INTR_FAST, then realize that you can only use spin mutexes in your handler, and that any more complicated work like selwakeup() that uses regular mutexes will have to be deferred either by using a swi handler or dispatching a task to the Fast taskqueue. -- John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/ Power Users Use the Power to Serve = http://www.FreeBSD.org ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: poll()/select()
Now, have checking non-FAST handler. Have some interest moments, such as error codes, like: Short write: 0/15 (Programming error) Write to 137 (fdno) failed: Programming error Maybe server becomes overloaded? (4xE1, Xeon 3G) Best regards, Konstantin Prokazoff Center Of Excellence, S_V_R Ltd., Kyiv HQs, Ukraine Official business-partner DevConnect member of Avaya Inc. Regional development support center of Digium Inc. Tel. +38 044 594 1781, ext. 1038 Fax. +38 044 234 0455 - Original Message - From: John Baldwin [EMAIL PROTECTED] To: freebsd-hackers@freebsd.org Cc: Konstantin Prokazoff [EMAIL PROTECTED] Sent: Monday, November 21, 2005 5:38 PM Subject: Re: poll()/select() On Monday 21 November 2005 08:14 am, Konstantin Prokazoff wrote: Thanks for comment, I think, after kernel inspection, problem (maybe) in preemption. While syscall to poll or select holds sellock, and if another thread (process) tries to syscall or we have taken interrupt (where handler use selrecord/selwakeup too), kernel will deadlock. I have this situation cause to INTR_FAST interrupt handler in device driver for Digium's PCI board, which provides 4 T1/E1 interfaces. Problem 100% repetitive. Another way to avoid such deadlock - provide different kthread/ithreads for select/poll mechanism. You can't call selwakeup() from an INTR_FAST handler. Try removing INTR_FAST and see if it fixes your issue. If you want to use INTR_FAST, then realize that you can only use spin mutexes in your handler, and that any more complicated work like selwakeup() that uses regular mutexes will have to be deferred either by using a swi handler or dispatching a task to the Fast taskqueue. -- John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/ Power Users Use the Power to Serve = http://www.FreeBSD.org ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 4.8 Alternate system clock has died error
On Tuesday 22 November 2005 04:35 am, Uwe Doering wrote:
Charles Sprickman wrote:
On Tue, 22 Nov 2005, Uwe Doering wrote:
Charles Sprickman wrote:
[...]
So it certainly looks easy enough for me to change the first two
sections of the diff referenced above, but I'm having issues finding
that last one in cpu_initclocks(). It looks like that section really
has changed quite a bit. (see v.1.206)
Just look for all instances of
writertc(RTC_STATUSB, rtc_statusb);
and put
rtcin(RTC_INTR);
directly behind them (into the next line). There should be three of
them, in 4.8 as well as RELENG_4 and CURRENT.
I found the first two (line 721 and 979) and I see third at line 1064.
One other question, looking at the initial patch
(http://www.freebsd.org/cgi/query-pr.cgi?pr=17800), I see that they
followed a slightly different line:
/* Initialize RTC. */
writertc(RTC_STATUSA, rtc_statusa);
writertc(RTC_STATUSB, RTCSB_24HR); ---
+rtcin(RTC_INTR); /* clear any pending interrupt */
Should I worry about that at all?
No. User supplied patches in PRs aren't necessarily 100% correct. In
this case the PR submitter clears pending interrupts while interrupt
generation is disabled. However, the committer of 1.214 (John Baldwin,
in fact) thought that this is wrong because you have to clear pending
interrupts after interrupt generation has been re-enabled, or else you'd
get a race condition. And I agree with that.
Yeah, put the rtcin() after both writes have been completed.
Is there any interest in moving this back to 4-STABLE?
Interest there is, I suppose. Plenty of people still run 4.x. The
question is rather whether there is any committer willing to do the
backport. As far as I can tell, most of them are more focused on
newer branches. Perhaps we need special backporting committers for
legacy branches. Just a thought. ;-)
Yeah, I work on a total of about 32 boxes, all still at either 4.8 or
4.11. Committers have to know C, right? :)
Not only that. In case of kernel issues they also have to have quite a
lot of knowledge and experience in kernel hacking. If you botch a
kernel patch and don't notice in time you'll likely cause quite a lot of
grief for the users.
Well, if your box boots ok with it then send me a diff in an e-mail and I'll
backport it. Note, however, that there isn't going to be a 4.12 release.
Does the RTC supply all timing in a system, or just time of day?
Just the latter (once at boot time) and also the RTC interrupt
('stathz'). Perhaps 'profhz' too, if you enable profiling. Can't tell
offhand.
Yes, it does provide profhz as well. When you start profiling a process, we
reprogram the RTC to interrupt at profhz and divided down to still call
statclock at stathz (see the fiddling with pscnt and psdiv).
How does this line relate to things? kern.clockrate: { hz = 100, tick =
1, tickadj = 5, profhz = 1024, stathz = 128 }
If the RTC doesn't supply the base timing for things like all the I/O
busses, processor, what does?
There's another clock device, which 'hz' is derived of, for example.
Perhaps one can call it the CPU clock. It drives the CPU, memory, PCI
bus etc. Also, while the system is running it drives the kernel's
time-of-day clock. However, the CPU clock's frequency isn't overly
accurate. That's why the kernel's time-of-day clock usually deviates
pretty much from the wall clock unless you apply some form of continuous
adjustment, for instance NTP.
Actually, the timer for 'hz' is ISA timer #0. There are three ISA timers, 0,
1, and 2. I have no idea if 1 has a common use though I don't think FreeBSD
uses it. timer 2 drives the pc speaker, and timer 0 can generate a periodic
interrupt. The three timers are in the i8254 chip (part of the southbridge
LPC stuff in modern systems). On 6.0 and later we do actually use a per-CPU
timer known as the lapic (short for Local APIC) timer to drive 'hz',
'stathz', and 'profhz' on systems using an APIC.
--
John Baldwin [EMAIL PROTECTED] http://www.FreeBSD.org/~jhb/
Power Users Use the Power to Serve = http://www.FreeBSD.org
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Core dump after RELENG_5_4 to RELENG_6_0
Core dump after RELENG_5_4 to RELENG_6_0
(kgdb) where
#0 doadump () at pcpu.h:165
#1 0xc04d2f92 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:399
#2 0xc04d3228 in panic (fmt=0xc064717a %s) at
/usr/src/sys/kern/kern_shutdown.c:555
#3 0xc062a698 in trap_fatal (frame=0xc7b97c2c, eva=0) at
/usr/src/sys/i386/i386/trap.c:831
#4 0xc062a403 in trap_pfault (frame=0xc7b97c2c, usermode=0, eva=0) at
/usr/src/sys/i386/i386/trap.c:742
#5 0xc062a061 in trap (frame=
{tf_fs = -1058078712, tf_es = -1058078680, tf_ds = -944177112,
tf_edi = -1057380052, tf_esi = 0, tf_ebp = -944145256, tf_isp =
-944145320, tf_ebx = 52, tf_edx = 128, tf_ecx = 13, tf_eax =
-1057380052, tf_trapno = 12, tf_err = 0, tf_eip = -1067284630, tf_cs =
32, tf_eflags = 66050, tf_esp = 0, tf_ss = -1057381320}) at
/usr/src/sys/i386/i386/trap.c:432
#6 0xc061a14a in calltrap () at /usr/src/sys/i386/i386/exception.s:139
#7 0xc062876a in generic_bcopy () at /usr/src/sys/i386/i386/support.s:489
Previous frame inner to this frame (corrupt stack?)
(kgdb)
#less /var/log/messages
Nov 22 16:40:39 gate syslogd: kernel boot file is /boot/kernel/kernel
Nov 22 16:40:39 gate kernel: Copyright (c) 1992-2005 The FreeBSD Project.
Nov 22 16:40:39 gate kernel: Copyright (c) 1979, 1980, 1983, 1986, 1988,
1989, 1991, 1992, 1993, 1994
Nov 22 16:40:39 gate kernel: The Regents of the University of
California. All rights reserved.
Nov 22 16:40:39 gate kernel: FreeBSD 6.0-RELEASE #0: Tue Nov 22 12:48:05
MSK 2005
Nov 22 16:40:39 gate kernel:
[EMAIL PROTECTED]:/usr/obj/usr/src/sys/iPII350_6_0_1
Nov 22 16:40:39 gate kernel: Timecounter i8254 frequency 1193182 Hz
quality 0
Nov 22 16:40:39 gate kernel: CPU: Pentium II/Pentium II Xeon/Celeron
(350.80-MHz 686-class CPU)
Nov 22 16:40:39 gate kernel: Origin = GenuineIntel Id = 0x652
Stepping = 2
Nov 22 16:40:39 gate kernel:
Features=0x183f9ffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR
Nov 22 16:40:39 gate kernel: real memory = 134205440 (127 MB)
Nov 22 16:40:39 gate kernel: avail memory = 125984768 (120 MB)
Nov 22 16:40:39 gate kernel: npx0: [FAST]
Nov 22 16:40:39 gate kernel: npx0: math processor on motherboard
Nov 22 16:40:39 gate kernel: npx0: INT 16 interface
Nov 22 16:40:39 gate kernel: acpi0: ASUS P2B on motherboard
Nov 22 16:40:39 gate kernel: acpi0: Power Button (fixed)
Nov 22 16:40:39 gate kernel: pci_link0: ACPI PCI Link LNKA irq 11 on acpi0
Nov 22 16:40:39 gate kernel: pci_link1: ACPI PCI Link LNKB irq 10 on acpi0
Nov 22 16:40:39 gate kernel: pci_link2: ACPI PCI Link LNKC irq 12 on acpi0
Nov 22 16:40:39 gate kernel: pci_link3: ACPI PCI Link LNKD irq 7 on acpi0
Nov 22 16:40:39 gate kernel: Timecounter ACPI-safe frequency 3579545
Hz quality 1000
Nov 22 16:40:39 gate kernel: acpi_timer0: 24-bit timer at 3.579545MHz
port 0xe408-0xe40b on acpi0
Nov 22 16:40:39 gate kernel: cpu0: ACPI CPU on acpi0
Nov 22 16:40:39 gate kernel: acpi_button0: Power Button on acpi0
Nov 22 16:40:39 gate kernel: pcib0: ACPI Host-PCI bridge port
0xcf8-0xcff on acpi0
Nov 22 16:40:39 gate kernel: pci0: ACPI PCI bus on pcib0
Nov 22 16:40:39 gate kernel: agp0: Intel 82443BX (440 BX) host to PCI
bridge mem 0xe400-0xe7ff at device 0.0 on pci0
Nov 22 16:40:39 gate kernel: pcib1: PCI-PCI bridge at device 1.0 on pci0
Nov 22 16:40:39 gate kernel: pci1: PCI bus on pcib1
Nov 22 16:40:39 gate kernel: pci1: display, VGA at device 0.0 (no
driver attached)
Nov 22 16:40:39 gate kernel: isab0: PCI-ISA bridge at device 4.0 on pci0
Nov 22 16:40:39 gate kernel: isa0: ISA bus on isab0
Nov 22 16:40:39 gate kernel: atapci0: Intel PIIX4 UDMA33 controller
port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xd800-0xd80f at device 4.1 on pci0
Nov 22 16:40:39 gate kernel: ata0: ATA channel 0 on atapci0
Nov 22 16:40:39 gate kernel: ata1: ATA channel 1 on atapci0
Nov 22 16:40:39 gate kernel: uhci0: Intel 82371AB/EB (PIIX4) USB
controller port 0xd400-0xd41f at device 4.2 on pci0
Nov 22 16:40:39 gate kernel: uhci0: [GIANT-LOCKED]
Nov 22 16:40:39 gate kernel: usb0: Intel 82371AB/EB (PIIX4) USB
controller on uhci0
Nov 22 16:40:39 gate kernel: usb0: USB revision 1.0
Nov 22 16:40:39 gate kernel: uhub0: Intel UHCI root hub, class 9/0, rev
1.00/1.00, addr 1
Nov 22 16:40:39 gate kernel: uhub0: 2 ports with 2 removable, self powered
Nov 22 16:40:39 gate kernel: pci0: bridge at device 4.3 (no driver
attached)
Nov 22 16:40:39 gate kernel: rl0: RealTek 8139 10/100BaseTX port
0xd000-0xd0ff mem 0xdb80-0xdb8000ff irq 7 at device 9.0 on pci0
Nov 22 16:40:39 gate kernel: miibus0: MII bus on rl0
Nov 22 16:40:39 gate kernel: rlphy0: RealTek internal media interface
on miibus0
Nov 22 16:40:39 gate kernel: rlphy0: 10baseT, 10baseT-FDX, 100baseTX,
100baseTX-FDX, auto
Nov 22 16:40:39 gate kernel: rl0: Ethernet address: 00:c0:df:26:7a:25
Nov 22 16:40:39 gate kernel: rl1: RealTek 8139 10/100BaseTX port
0xb800-0xb8ff mem 0xdb00-0xdbff irq 12 at device 10.0 on pci0
Nov 22 16:40:39 gate kernel: miibus1:
Re: poll()/select()
On Tuesday 22 November 2005 05:12 am, Konstantin Prokazoff wrote: Now, have checking non-FAST handler. Have some interest moments, such as error codes, like: Short write: 0/15 (Programming error) Write to 137 (fdno) failed: Programming error Maybe server becomes overloaded? (4xE1, Xeon 3G) Hmm, you really shouldn't be getting Programming error (EDOOFS) in userland, or are these messages from your driver? -- John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/ Power Users Use the Power to Serve = http://www.FreeBSD.org ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: poll()/select()
On Tuesday 22 November 2005 04:19 am, Konstantin Prokazoff wrote: Welcome, John, thanks for the answer. I'll test today bus_setup_intr() without INTR_FAST flag, but how I remember, this cause to system heavy load for interrupt processing ;( in my case. My handler uses spin mutexes to block inter-interrupting sleep mutexes to block some structures now. I have tried to use swi/taskqueue, but result is a sync degradation level. Can you help with sources briefing in my driver case? Thnx in advance. Well, I'm not quite sure what you mean by sync degradation level for starters, but I'm not much an expert on synchronous serial devices. What kind of load are you seeing on your system with the non-INTR_FAST handler? And what kind of system (CPU, etc.) are you running FreeBSD on? I have this situation cause to INTR_FAST interrupt handler in device driver for Digium's PCI board, which provides 4 T1/E1 interfaces. -- John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/ Power Users Use the Power to Serve = http://www.FreeBSD.org ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Question about closeing and opening stdin
How do I close then open stdin and keep it set to the same terminal as when it was closed? Everything I've tried so far has met with failure accept this works sort of and I don't get why: signal( SIGALRM, MGPMrTimer ); alarm( 300 ); /* time out in 5 minutes */ answer = getc(stdin); the signal handler just closes descriptor 0 if a timeout occrs: close( 0 ) then to reset stdin I tried this: stdinFileDescriptor = open( /dev/tty, O_RDWR ) ) stdin = fdopen( stdinFileDescriptor, r ); and it works in this instance of the program, but if a second instance is started the second instance can't close stdin. I got the above idea from google, what I don't understand though is there is no /dev/tty! So anyone have any suggested books I might read or tips so I can learn how to do this right, and understand why it works? Thank you, Mike ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Core dump after RELENG_5_4 to RELENG_6_0
On Tue, Nov 22, 2005 at 06:09:51PM +0300, Igor wrote:
Core dump after RELENG_5_4 to RELENG_6_0
(kgdb) where
#0 doadump () at pcpu.h:165
#1 0xc04d2f92 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:399
#2 0xc04d3228 in panic (fmt=0xc064717a %s) at
/usr/src/sys/kern/kern_shutdown.c:555
#3 0xc062a698 in trap_fatal (frame=0xc7b97c2c, eva=0) at
/usr/src/sys/i386/i386/trap.c:831
#4 0xc062a403 in trap_pfault (frame=0xc7b97c2c, usermode=0, eva=0) at
/usr/src/sys/i386/i386/trap.c:742
#5 0xc062a061 in trap (frame=
{tf_fs = -1058078712, tf_es = -1058078680, tf_ds = -944177112,
tf_edi = -1057380052, tf_esi = 0, tf_ebp = -944145256, tf_isp =
-944145320, tf_ebx = 52, tf_edx = 128, tf_ecx = 13, tf_eax =
-1057380052, tf_trapno = 12, tf_err = 0, tf_eip = -1067284630, tf_cs =
32, tf_eflags = 66050, tf_esp = 0, tf_ss = -1057381320}) at
/usr/src/sys/i386/i386/trap.c:432
#6 0xc061a14a in calltrap () at /usr/src/sys/i386/i386/exception.s:139
#7 0xc062876a in generic_bcopy () at /usr/src/sys/i386/i386/support.s:489
Previous frame inner to this frame (corrupt stack?)
(kgdb)
Did you remember to rebuild all your modules (e.g. any third-party
modules like the nvidia driver)?
Kris
pgpUoUPSgBusb.pgp
Description: PGP signature
Re: Question about closeing and opening stdin
On Tuesday 22 November 2005 10:50, Michael C. Shultz wrote: How do I close then open stdin and keep it set to the same terminal as when it was closed? Everything I've tried so far has met with failure accept this works sort of and I don't get why: signal( SIGALRM, MGPMrTimer ); alarm( 300 ); /* time out in 5 minutes */ answer= getc(stdin); the signal handler just closes descriptor 0 if a timeout occrs: close( 0 ) then to reset stdin I tried this: stdinFileDescriptor = open( /dev/tty, O_RDWR ) ) stdin = fdopen( stdinFileDescriptor, r ); and it works in this instance of the program, but if a second instance is started the second instance can't close stdin. I got the above idea from google, what I don't understand though is there is no /dev/tty! So anyone have any suggested books I might read or tips so I can learn how to do this right, and understand why it works? Thank you, Mike Please disregard the previous post, I figured it out, simple solution. -Mike ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ATI drivers for FreeBSD - anything?
On Mon, 21 Nov 2005, Maxime Henrion wrote: Albert Vest wrote: On Sat, 19 Nov 2005 01:58:25 +0200 (EET) Vladimir Kushnir [EMAIL PROTECTED] wrote: Hi all, Is there any project on FreeBSD wrapper for ATI Linux drivers (like nVidia's used to be)? If so - I'd be more than happy to test (sorry I can hardly write it myself). Regards, Vladimir I too would welcome this, mainly for ATI sound but also for video. I see the x11/nvidia-driver port can still be built with LINUX compatibility turned on; maybe if we make extract with LINUX=yes, the source code will contain some hints to how it can be done? The Linux compatibility in the nvidia-driver has nothing to do with a wrapper to run Linux drivers; nVidia releases a build of this driver for FreeBSD. The Linux compatibility option is here to install nVidia's Linux OpenGL libraries so that Linux binaries can run with FreeBSD's driver. This is possible because nVidia's OpenGL libraries communicate with the driver by using /dev/nvidia and the FreeBSD driver offers the same interface. In short, there is no easy way to use the ATI drivers for Linux under FreeBSD. True, but before they've started releasing them there was a wrapper in ports which used the Linux driver (and I think that was what motivated nVidia to release FreeBSD drivers). I just thought might be somebody who knows better than myself woud feel interested enough to write a similar wrapper for ATI drivers (which could eventualy stir them towards the same direction as nVidia). It looks I was wrong. A pity. Regards, Vladimir ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD Status Report Third Quarter 2005
When I initially wrote the Ports Status report I included information about a project that Edwin Groothuis created. At that time I neglected to get his approval for that text, and that was an oversight and a mistake on my part and I apologize. I did not intend for anyone to get the impression that anyone other than himself should get the credit for this project. mcl ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Xen dom0 support
Hello, I know Kip Macy was working on Xen support for FreeBSD. How is FreeBSD Dom0 coming along as well as SMP support ? -- Darcy Buskermolen Wavefire Technologies Corp. http://www.wavefire.com ph: 250.717.0200 fx: 250.763.1759 ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
getdirentries_args and other kernel syscall structures
Ok, I'va got a little question here. In the structure
getdirentries_args, there seems to be duplicated fields that I'm not
entirely sure what they do. Here's the definition of a structure
verbatim from sys/sysproto.h:
struct getdirentries_args {
char fd_l_[PADL_(int)]; int fd; char fd_r_[PADR_(int)];
char buf_l_[PADL_(char *)]; char * buf; char buf_r_[PADR_(char *)];
char count_l_[PADL_(u_int)]; u_int count; char
count_r_[PADR_(u_int)];
char basep_l_[PADL_(long *)]; long * basep; char
basep_r_[PADR_(long *)];
};
Now my question is what does the l and r variables do? It seems that
they do something with padding the data based on the endian of the
machine? I look through this header file, and I see all the structures
have similar constructs. Is it something that can be safely ignored?
--
Daniel Rudy
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Xen dom0 support
Le Tuesday 22 November 2005 23:17, Darcy Buskermolen a écrit : Hello, I know Kip Macy was working on Xen support for FreeBSD. How is FreeBSD Dom0 coming along as well as SMP support ? Hello, With the instructions on Kip's site or the patch included with the xen sources, it's possible to build a functioning XenU kernel. (I have run it under NetBSD/Xen0 and Debian/Linux2.6/Xen0). One limitation is that all patches have developed for 5.3-Release, and have not been recently updated. I have found the FreeBSD/Xen0 very unstable : I had crashes under even moderate load, and I did not see how to add debugging DDB support (but I did not look very far) Too bad : even just a Xen0 support would be fine (but Xen3 should make it possible to run an untouched FreeeBSD kernel on a DomU virtual machine) TfH TfH ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
gdb konsole system crash
Hello all! Discovering troubles with kde-apps startup I've faced with interesting effect - starting of gdb konsole (as nonprivileged user) causes system crash. Here is an example: gdb konsole run In my case this method 100% rebooting system in 80 seconds (mysterious network wait). On konsole appears this message: [EMAIL PROTECTED]:~ gdb konsole GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type show copying to see the conditions. There is absolutely no warranty for GDB. Type show warranty for details. This GDB was configured as amd64-marcel-freebsd...(no debugging symbols found)... (gdb) run Starting program: /usr/local/bin/konsole (no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...warning: Unable to get location for thread creation breakpoint: generic error [New LWP 100082] (no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...[New Thread 0x50c000 (LWP 100082)] (no debugging symbols found)...(no debugging symbols found)...kbuildsycoca running... Then after 80 seconds: [New Thread 0x50c400 (LWP 100128)] and system reboots. Maybe someone has faced with such problem on amd64 platform? Could you try to repeat this situation on other systems, or it's only my computer problem? My system: [EMAIL PROTECTED]:~ uname -a FreeBSD callisto 6.0-STABLE FreeBSD 6.0-STABLE #0: Sat Nov 19 14:31:34 EET 2005 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/callisto amd64 I'm keeping up my system actual, ports are updating regullary. -- WBR Android Andrew [:] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
sym(4) broken on amd64 (Time to port new driver?)
Looks like it is broken for a while - _sym_calloc2: failed to allocate HCB is always there... And... Looks like Gerard Roudier havn't more interest in maintaining this driver - there is the second generation of the original driver into linux source three since 2001, which is newer ported to FreeBSD by the author. And FreeBSD hooks was removed from the driver code... May be it is a time to port siop(4) from NetBSD? Serg N. Voronkov, Sibitex Ltd. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Core dump after RELENG_5_4 to RELENG_6_0
Core dump after RELENG_5_4 to RELENG_6_0
(kgdb) where
#0 doadump () at pcpu.h:165
#1 0xc04d2f92 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:399
#2 0xc04d3228 in panic (fmt=0xc064717a %s) at
/usr/src/sys/kern/kern_shutdown.c:555
#3 0xc062a698 in trap_fatal (frame=0xc7b97c2c, eva=0) at
/usr/src/sys/i386/i386/trap.c:831
#4 0xc062a403 in trap_pfault (frame=0xc7b97c2c, usermode=0, eva=0) at
/usr/src/sys/i386/i386/trap.c:742
#5 0xc062a061 in trap (frame=
{tf_fs = -1058078712, tf_es = -1058078680, tf_ds = -944177112,
tf_edi = -1057380052, tf_esi = 0, tf_ebp = -944145256, tf_isp =
-944145320, tf_ebx = 52, tf_edx = 128, tf_ecx = 13, tf_eax =
-1057380052, tf_trapno = 12, tf_err = 0, tf_eip = -1067284630, tf_cs =
32, tf_eflags = 66050, tf_esp = 0, tf_ss = -1057381320}) at
/usr/src/sys/i386/i386/trap.c:432
#6 0xc061a14a in calltrap () at /usr/src/sys/i386/i386/exception.s:139
#7 0xc062876a in generic_bcopy () at /usr/src/sys/i386/i386/support.s:489
Previous frame inner to this frame (corrupt stack?)
(kgdb)
Did you remember to rebuild all your modules (e.g. any third-party
modules like the nvidia driver)?
Did as in /usr/src/Makefile
[skip]
# 1. `cd /usr/src' (or to the directory containing your source tree).
# 2. `make buildworld'
# 3. `make buildkernel KERNCONF=YOUR_KERNEL_HERE' (default is GENERIC).
# 4. `make installkernel KERNCONF=YOUR_KERNEL_HERE' (default is GENERIC).
# 5. `reboot'(in single user mode: boot -s from the loader prompt).
# 6. `mergemaster -p'
# 7. `make installworld'
# 8. `mergemaster'
# 9. `reboot'
[skip]
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
