Re: r269471 make unusable VT console

2014-08-19 Thread Adrian Chadd
Hi, On 19 August 2014 12:40, Jean-Sébastien Pédron wrote: > On 19.08.2014 21:20, Adrian Chadd wrote: >> Hey, this is cool! >> >> So hm, why are you still doing any reading? Don't you now have all the >> information you need to write out the font and cursor information for >> each given set of 8

Re: r269471 make unusable VT console

2014-08-19 Thread Nathan Whitehorn
On 08/19/14 12:02, Jean-Sébastien Pédron wrote: On 19.08.2014 19:46, Nathan Whitehorn wrote: On 08/19/14 09:28, Jean-Sébastien Pédron wrote: o vt_vga introduces a new callback, vd_bitblt_text_t, which takes as argument the text buffer, the dirty area, the font and the

Re: r269471 make unusable VT console

2014-08-19 Thread Jean-Sébastien Pédron
On 19.08.2014 21:20, Adrian Chadd wrote: > Hey, this is cool! > > So hm, why are you still doing any reading? Don't you now have all the > information you need to write out the font and cursor information for > each given set of 8 pixels? I read a lot about VGA in the past days but I'm new to thi

Re: r269471 make unusable VT console

2014-08-19 Thread Adrian Chadd
Hey, this is cool! So hm, why are you still doing any reading? Don't you now have all the information you need to write out the font and cursor information for each given set of 8 pixels? -a ___ freebsd-current@freebsd.org mailing list http://lists.fre

Re: r269471 make unusable VT console

2014-08-19 Thread Jean-Sébastien Pédron
On 19.08.2014 19:46, Nathan Whitehorn wrote: > On 08/19/14 09:28, Jean-Sébastien Pédron wrote: >> o vt_vga introduces a new callback, vd_bitblt_text_t, which takes >> as argument the text buffer, the dirty area, the font and the >> cursor (position, map, colors). > > Why is th

Re: r269471 make unusable VT console

2014-08-19 Thread Nathan Whitehorn
On 08/19/14 09:28, Jean-Sébastien Pédron wrote: On 19.08.2014 10:42, Jean-Sébastien Pédron wrote: On 16.08.2014 01:51, Nathan Whitehorn wrote: It also has bad effects on boot time. My desktop takes something like 3 times as long to boot after r269471. If it can't be fixed quickly, it needs to

Re: r269471 make unusable VT console

2014-08-19 Thread Jean-Sébastien Pédron
On 19.08.2014 10:42, Jean-Sébastien Pédron wrote: > On 16.08.2014 01:51, Nathan Whitehorn wrote: >> It also has bad effects on boot time. My desktop takes something like 3 >> times as long to boot after r269471. If it can't be fixed quickly, it >> needs to be reverted. > > Just a quick note: I'm w

Re: panic: pmap active 0xfffff8002d2ae9f8

2014-08-19 Thread Bryan Drewery
On 8/18/2014 3:41 AM, Konstantin Belousov wrote: > On Fri, Aug 15, 2014 at 10:38:25PM -0500, Bryan Drewery wrote: >> On 2014-08-13 10:38, Bryan Drewery wrote: >>> On 6/24/2014 4:28 PM, Craig Rodrigues wrote: Hi, I have a system running CURRENT at r266925 from May 31. While

Re: DEADLKRES crash

2014-08-19 Thread Bryan Drewery
On 8/19/2014 8:53 AM, Larry Rosenman wrote: > On 2014-08-19 08:42, Eric van Gyzen wrote: >> On 08/18/2014 16:45, Ryan Stone wrote: >>> The first thing that I'd like to see is (in kgdb): >>> >>> set $td=(struct thread)0xf8002abeb000 >>> tid $td->td_tid >>> bt >>> >>> That will show us the backtr

Re: nscd not caching

2014-08-19 Thread Harald Schmalzbauer
Bezüglich Eric van Gyzen's Nachricht vom 19.08.2014 15:39 (localtime): > On 08/19/2014 09:14, Harald Schmalzbauer wrote: >> … >>> At least that's what we found in the freebsd.org cluster. nss-pam-ldapd >>> was >>> two or three orders of magnitude more usable and got rid of nscd in the >>> pro

Re: DEADLKRES crash

2014-08-19 Thread Larry Rosenman
On 2014-08-19 08:42, Eric van Gyzen wrote: On 08/18/2014 16:45, Ryan Stone wrote: The first thing that I'd like to see is (in kgdb): set $td=(struct thread)0xf8002abeb000 tid $td->td_tid bt That will show us the backtrace of the thread that was blocked for so long. Make that: set $td=(

Re: DEADLKRES crash

2014-08-19 Thread Eric van Gyzen
On 08/18/2014 16:45, Ryan Stone wrote: > The first thing that I'd like to see is (in kgdb): > > set $td=(struct thread)0xf8002abeb000 > tid $td->td_tid > bt > > That will show us the backtrace of the thread that was blocked for so long. Make that: set $td=(struct thread *)0xf8002abeb000 t

Re: nscd not caching

2014-08-19 Thread Eric van Gyzen
On 08/19/2014 09:14, Harald Schmalzbauer wrote: > Bezüglich Peter Wemm's Nachricht vom 17.08.2014 19:18 (localtime): >> On Sunday 17 August 2014 15:22:02 O. Hartmann wrote: >>> Am Sun, 17 Aug 2014 13:09:10 + >>> >>> "Eggert, Lars" schrieb: Nobody using nscd? Really? >>> I can only speak

Re: nscd not caching

2014-08-19 Thread Eggert, Lars
On 2014-8-19, at 13:54, Daniel Braniss wrote: > > I know that this a bit late but have you ever considered Hesiod? it uses > DNS/txt. > we have been using it since the days when BSDi had no NIS support and haven’t > seen a ypserver not responding since :-) I don't control the master NIS infrast

Re: nscd not caching

2014-08-19 Thread Eggert, Lars
On 2014-8-18, at 20:23, John-Mark Gurney wrote: > Why not run a local slave on your server? I am trying to get one set up. It requires a change request to our organization's IT, which is, ahem, not always lightning fast. Lars signature.asc Description: Message signed with OpenPGP using GPGMai

Re: nscd not caching

2014-08-19 Thread Harald Schmalzbauer
Bezüglich Peter Wemm's Nachricht vom 17.08.2014 19:18 (localtime): > On Sunday 17 August 2014 15:22:02 O. Hartmann wrote: >> Am Sun, 17 Aug 2014 13:09:10 + >> >> "Eggert, Lars" schrieb: >>> Nobody using nscd? Really? >> I can only speak for myself and I stopped using nscd since the support is

Re: nscd not caching

2014-08-19 Thread Daniel Braniss
On Aug 18, 2014, at 10:42 AM, Eggert, Lars wrote: > Hi, > > On 2014-8-17, at 18:10, Adam McDougall wrote: >> We were using +: type entries in the local password and group >> tables and I believe we used an unmodified /etc/nsswitch.conf (excluding >> cache lines while testing nscd): >

Re: r269471 make unusable VT console

2014-08-19 Thread Jean-Sébastien Pédron
On 16.08.2014 01:51, Nathan Whitehorn wrote: > It also has bad effects on boot time. My desktop takes something like 3 > times as long to boot after r269471. If it can't be fixed quickly, it > needs to be reverted. Just a quick note: I'm working on an update to vt_vga. The current patch already fi