m the current uses.
Please review the patch. Note I didn't really remove get_cyclecount()
just because some random third-party module may use it as it is a
documented feature while cpu_ticks is an internal KPI.
What do you think?
Jung-uk Kim
Index: sys/kern/
/quirks individually per-core. I think
> that we assume that all cores have the same stepping and thus
> require the same workarounds, if any, as BSP. Also, I think tsc
> calibration is done only on BSP, but I may be wrong there.
Yeah, it is just sad but that's what we do now. Just for
x gives me really
wacky TSC frequency sometimes. When it happens, it becomes unusably
slow. So, I know something is really wrong there, too. However, Xen
seems to do much smarter than that because it has its own concept of
virtual TSC, thanks to its para-virtualization architecture.
Jung-uk
On Friday 18 March 2011 04:11 pm, Kostik Belousov wrote:
> On Fri, Mar 18, 2011 at 02:09:58PM -0400, Jung-uk Kim wrote:
> > On Friday 18 March 2011 01:05 pm, Bruce Evans wrote:
> > > On Sat, 19 Mar 2011, Bruce Evans wrote:
> > > > On Fri, 18 Mar 2011, Kostik Belousov
heers,
Jung-uk Kim
Index: sys/x86/x86/tsc.c
===
--- sys/x86/x86/tsc.c (revision 62)
+++ sys/x86/x86/tsc.c (working copy)
@@ -79,7 +79,8 @@ static void tsc_freq_changed(void *arg, const stru
int status);
static
On Tuesday 31 May 2011 07:18 am, Andriy Gapon wrote:
> on 24/05/2011 20:56 Jung-uk Kim said the following:
> > I think it's about time to enable invariant TSC timecounter on
> > SMP by default. Please see the attached patch. It is also
> > available from here:
> &g
On Wednesday 01 June 2011 01:40 am, Andriy Gapon wrote:
> on 31/05/2011 23:16 Jung-uk Kim said the following:
> > On Tuesday 31 May 2011 07:18 am, Andriy Gapon wrote:
> >> on 24/05/2011 20:56 Jung-uk Kim said the following:
> >>> I think it's about time to
On Friday 03 June 2011 02:03 am, Andriy Gapon wrote:
> on 01/06/2011 23:55 Jung-uk Kim said the following:
> > Yes, it's still a work-in-progress. However, I thought it is
> > good enough for 9.0 inclusion. BTW, the latest patch is here:
> >
> > http://people.free
gt;
> I would try to add some printfs (or used dtrace - whichever is
> easier for you) to see what's going on. Or you can even use
> pciconf to directly sneak a peek at what's reported by the
> hardware, e.g.:
> # pciconf -r pci0:0:24:3 0xa4
> 1c881880
>
> You
ng is worth noting though. I have used a free gadget that
> shows activity/temp for each core. It worked fine with the previous
> MB/CPU.That ALSO stopped working with this new MB. Like FBSD, it
> shows 0 degrees for any core too, although it correctly displays
> each core load.
>
>
On Monday 01 August 2011 03:03 pm, Andriy Gapon wrote:
> [cc list trimmed]
>
> on 01/08/2011 19:23 Jung-uk Kim said the following:
> > I gave up the DiodeOffset recently because a lot of BIOSes do not
> > set any meaningful values. Instead, I added a tunable for that.
> &
On Monday 01 August 2011 04:10 pm, Andriy Gapon wrote:
> on 01/08/2011 22:48 Jung-uk Kim said the following:
> > I have mixed feeling about this because I own a system with such
> > CPU/motherboard combo, too. I also believe it works well but
> > errata is errata. If vendor
On Monday 01 August 2011 04:07 pm, Andriy Gapon wrote:
> on 01/08/2011 22:48 Jung-uk Kim said the following:
> > amdtemp(4) attaches under PCI bus but its sibling on function 2
> > isn't easy to address, i.e., hostbN.
>
> pci_find_bsf() should help with that.
I though
On Sunday 21 August 2011 06:13 am, Andriy Gapon wrote:
> on 02/08/2011 00:06 Jung-uk Kim said the following:
> > On Monday 01 August 2011 04:10 pm, Andriy Gapon wrote:
> >> on 01/08/2011 22:48 Jung-uk Kim said the following:
> >>> I have mixed feeling about th
t was on the WantedPorts list
on Wiki for a while. If anyone with more clues want to pick it up
from here, please feel free.
Cheers,
Jung-uk Kim
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hacke
On Friday 09 September 2011 11:53 am, arrowdodger wrote:
> On Fri, Sep 9, 2011 at 2:11 AM, Jung-uk Kim
wrote:
> > I have done preliminary porting work of PathScale's open-sourced
> > EKOPath Compiler Suite (https://github.com/pathscale).
> >
> > http://
On Friday 09 September 2011 12:49 pm, "C. Bergström" wrote:
> On 09/ 9/11 10:53 PM, arrowdodger wrote:
> > On Fri, Sep 9, 2011 at 2:11 AM, Jung-uk Kim
wrote:
> >> I have done preliminary porting work of PathScale's open-sourced
> >> EKOPath Co
On Thursday 08 September 2011 06:11 pm, Jung-uk Kim wrote:
> I have done preliminary porting work of PathScale's open-sourced
> EKOPath Compiler Suite (https://github.com/pathscale).
>
> http://people.freebsd.org/~jkim/ekopath-devel.tar.bz2
I just uploaded a new tarball, ekopa
On Friday 09 September 2011 06:38 pm, Jung-uk Kim wrote:
> On Thursday 08 September 2011 06:11 pm, Jung-uk Kim wrote:
> > I have done preliminary porting work of PathScale's open-sourced
> > EKOPath Compiler Suite (https://github.com/pathscale).
> >
> > http://
/query-pr.cgi?pr=162338
After I reviewed it, I told him it isn't right because it messes up
with source directories. Instead, I suggested him to add the new
feature. ;-)
Please review and let me know what you think.
Cheers!
Jung-uk Kim
PS: Do we care about submitting it back to NetBSD? Act
d.org/dragonfly.git/commit/8e32ecc0a77082f1e232a3e6d12e2f163f9667a4
Jung-uk Kim
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
utils/dmidecode.
You don't have to use dmidecode for that. The same information is
already available from loader(8) for very long time:
% kenv smbios.memory.enabled
4194304
% dmesg | grep 'real memory'
real memory = 4294967296 (4096 MB)
http://svnweb.freebsd.org/
repeats 983070 times. Strings with were very
> long, I truncated them for readability. This is odd.
>
> 1.
> http://www.oleg-sharoyko.net/files/freebsd/pci_config.201008/Xorg.v
>esa.log
Basically, it means the video ROM is not accessible or failed to POST.
FYI, Mac's don't
iew=revision&revision=210303
> However, NVIDIA suspend/resume is largely untested on FreeBSD.
That's very sad news. :-(
Jung-uk Kim
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
ing. Are you sure the option ROM
is actually real mode code but not shadowed again after resume? FYI,
you can add a printf() in sys/dev/fb/vesa.c like this to verify, I
think:
if (x86bios_get_orm(0xc) == NULL) {
printf("No option ROM found\n");
On Monday 16 August 2010 02:21 pm, Jung-uk Kim wrote:
> On Monday 16 August 2010 12:46 pm, Oleg Sharoyko wrote:
> > On 6 August 2010 08:15, Oleg Sharoyko wrote:
> > >> When using the NVIDIA driver, you will need to make sure that
> > >> you're using 256.44, y
On Thursday 19 August 2010 12:48 am, Oleg Sharoyko wrote:
> On 16 August 2010 22:21, Jung-uk Kim wrote:
> > In theory, we can shadow video ROM and execute it in emulation
> > *iff* it actually contains x86 real mode code. It won't be too
> > hard but I am not sure
; > Big thanks to Matthew and his employer for the idea and example.
>
> One note. Use 'cpu_spinwait()' in the inner loop waiting for
> 'stopping_cpu' to change.
+1.
Jung-uk Kim
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
mid.cgi?200911181926.nAIJQHOR081471
Jung-uk Kim
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
DBY_IMMEDIATE, 0, 0, 0);
> +return 0;
> +
> if (atadev->param.support.command2 & ATA_SUPPORT_FLUSHCACHE)
> ata_controlcmd(dev, ATA_FLUSHCACHE, 0, 0, 0);
> return 0;
I am not 100% sure but I think it should be something like the
attached patch.
Ju
ive) and /dev/cd0
> (an optical drive). Are you sure it works on Linux?
Can you please try ioctl(fd, BLKGETSIZE64, &some_uint64_var) or
ioctl(fd, BLKGETSIZE, &some_u_long_var)?
Jung-uk Kim
___
freebsd-hackers@freebsd.org mailing list
http://
ated.
Just for the record, I added CPUID_TO_* macros and I absolutely agree
that we don't need CPUID_TO_STEPPING().
> I do have a version of your patch I plan to commit soon.
Thanks!
Jung-uk Kim
___
freebsd-hackers@freebsd.org mailing list
http
While I was debugging syscalls, I found a very useful field in struct
thread, td_errno. It seems it was added for dtrace but it is only
populated on amd64 and i386. Is the attached patch acceptable for
maintainers of other platforms?
Thanks,
Jung-uk Kim
Index: sys/arm/arm/trap.c
On Thursday 11 March 2010 04:55 pm, Marcel Moolenaar wrote:
> On Mar 11, 2010, at 1:24 PM, Jung-uk Kim wrote:
> > While I was debugging syscalls, I found a very useful field in
> > struct thread, td_errno. It seems it was added for dtrace but it
> > is only populated on am
On Friday 12 March 2010 04:29 am, Kostik Belousov wrote:
> On Thu, Mar 11, 2010 at 06:15:07PM -0500, Jung-uk Kim wrote:
> > On Thursday 11 March 2010 04:55 pm, Marcel Moolenaar wrote:
> > > On Mar 11, 2010, at 1:24 PM, Jung-uk Kim wrote:
> > > > While I was debu
On Friday 12 March 2010 01:32 pm, Jung-uk Kim wrote:
> On Friday 12 March 2010 04:29 am, Kostik Belousov wrote:
> > On Thu, Mar 11, 2010 at 06:15:07PM -0500, Jung-uk Kim wrote:
> > > On Thursday 11 March 2010 04:55 pm, Marcel Moolenaar wrote:
> > > > On Mar 11, 2010,
On Monday 15 March 2010 02:10 pm, Jung-uk Kim wrote:
> On Friday 12 March 2010 01:32 pm, Jung-uk Kim wrote:
> > On Friday 12 March 2010 04:29 am, Kostik Belousov wrote:
> > > On Thu, Mar 11, 2010 at 06:15:07PM -0500, Jung-uk Kim wrote:
> > > > On Thursday 11 March 2
Although I really like logo_saver with Beastie, we have the official
FreeBSD logo and I think it is time to say good-bye to the old logo
image file. The attached file is a drop-in replacement for
sys/dev/syscons/logo/logo.c.
What do you think?
Jung-uk Kim
* PS: I couldn't find a good
On Wednesday 07 April 2010 05:23 am, Garrett Cooper wrote:
> On Wed, Apr 7, 2010 at 2:19 AM, Peter Pentchev
wrote:
> > On Wed, Apr 07, 2010 at 09:18:09AM +0200, Dag-Erling Sm??rgrav
wrote:
> >> Jung-uk Kim writes:
> >> > Although I really like logo_s
Hi, all.
Is there anybody interested in AMD x86-64 architecture? I think we
should take a look at this.
http://www.x86-64.org/
- Jung-uk Kim
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
eal with, however I've been told they will not prevent
> me from releasing driver source.
AFAIK, CX25870/1 is a video encoder.
http://www.conexant.com/products/entry.jsp?id=278
Jung-uk Kim
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.or
We've got a brand new Compaq ProLiant DL380 G2 machine but floppy drive
wasn't working at all with FreeBSD 4.x.
I found that there was a PR:
http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/21397
I got the following error messages:
Apr 16 16:57:48 /kernel: fdc0: direction bit not set
Apr 16 1
Here is the patch against 5.0-CURRENT. Please note that it wasn't
tested. ;-)
Thanks,
JK
--- sys/isa/fd.c.oldTue Apr 2 13:29:43 2002
+++ sys/isa/fd.cThu Apr 18 17:42:03 2002
@@ -563,13 +563,15 @@
return fdc_err(fdc, "Enable FIFO failed\n");
Can we let sysinstall sanitize geometry while non-interactive
installation? This patch can be applied on src/release of 4.5-STABLE or
src/usr.sbin of 5.0-CURRENT.
Sorry for the whining but recent acquisition of Compaq ProLiant DL380 G2
made me do it. :-(
Thanks,
JK
--- sysinstall/disks.c
Hi,
I read an article about Linux BIOS project on Slashdot.org. Is there
anybody working on FreeBSD BIOS?
I really like to see something like 'boot net - install' or serial
console. It would be cool to have dignostics routine, too.
J
boards.
Which means I cannot use it since I don't have the NIC and I don't want to
buy the hardware for this. I want 'PXE' from BIOS so that I can keep my
cards. :)
Second, the motherboard I have doesn't support serial console. I couldn't
find any BIOS update for the
46 matches
Mail list logo
