On Thu, 4 May 2006 11:29:23 +0530 [EMAIL PROTECTED] wrote:
>
> Thanks Randy. Can you please explain it elaboraly.
> What I mean, is why this sparse static checker is used and is there any
> toll to use it ?
The tool to use it is called 'sparse'. You can get it from its
git repository (you can v
On Thu, 4 May 2006 11:13:20 +0530 [EMAIL PROTECTED] wrote:
> Hi all,
> I came across two macros __releases and __acquires defined in
> compiler.h.
> Can anyone please tell me the exact use of these two macros.
They are for the sparse static checker to count locks released
and acquired, to mak
On Wed, May 03, 2006 at 09:52:11PM -0700, Nathan Becker wrote:
> Hi,
>
> I recently added two more memory modules to my Gigabyte K8NXP-SLI
> motherboard, bringing the total up to 4GB. I had 2GB previously and
> things were running well with kernel 2.6.16.9 x86_64. The CPU is an
> AMD 4800+ X2.
>
Begin forwarded message:
Date: Wed, 3 May 2006 14:23:07 -0700
From: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: [Bug 6489] New: High Speed USB devices don't work when ehci_hcd loaded
(nforce4)
http://bugzilla.kernel.org/show_bug.cgi?id=6489
Summary: High Speed USB devices don
On Wed, May 03, 2006 at 12:53:21PM -0700, Pete Zaitcev wrote:
> On Wed, 3 May 2006 12:55:49 -0400, Glenn Maynard <[EMAIL PROTECTED]> wrote:
>
> > int get_us_type(const struct us_data *us)
> > {
> > // flags that don't indicate that a device won't work with UB:
> > int permitted_flags = US_
On Wed, 3 May 2006, Pete Zaitcev wrote:
> On Tue, 2 May 2006 10:31:14 -0700, Matthew Dharm <[EMAIL PROTECTED]> wrote:
>
> > > > So what criteria did you use to decide whether to set it to
> > > > USB_US_TYPE_STOR or "0"? I'm assuming 0 means usb-storage?
> > >
> > > No, zero means "runtime-selec
I've done some of the requisite homework myself for getting full speed
audio devices to work properly through ehci and TTs on a 2.0 hub
(playback *and* capture). At this point it all works although my
changes are not production-ready.
I have three specific questions for now.
The primary reason
On Tue, 2 May 2006 10:31:14 -0700, Matthew Dharm <[EMAIL PROTECTED]> wrote:
> > > So what criteria did you use to decide whether to set it to
> > > USB_US_TYPE_STOR or "0"? I'm assuming 0 means usb-storage?
> >
> > No, zero means "runtime-selectable". The ub only works with 8/6/50
> > devices, so
On Wed, 3 May 2006 12:55:49 -0400, Glenn Maynard <[EMAIL PROTECTED]> wrote:
> int get_us_type(const struct us_data *us)
> {
> // flags that don't indicate that a device won't work with UB:
> int permitted_flags = US_FL_FIX_CAPACITY;
> if((us->flags & ~permitted_flags) != 0)
> r
On Wednesday 03 May 2006 12:10 pm, David Brownell wrote:
> Well, it's always allowed driver modularization ... the change was only
> to move the hardware-specific parts outside of the driver core.
Bad wording there. Last September I submitted patches to split out
the driver core and the hardware
On Wednesday 03 May 2006 7:44 am, David Hollis wrote:
> Correct. He is violating the license in a number of ways, though it
> probably isn't totally intentional.
Removing copyright and licence statements can't have been anything BUT
intentional.
That's really a basic rule, pretty much a "program
On Wed, 3 May 2006, Glenn Maynard wrote:
> I think all I was visualizing was eg:
>
> int get_us_type(const struct us_data *us)
> {
> // flags that don't indicate that a device won't work with UB:
> int permitted_flags = US_FL_FIX_CAPACITY;
> if((us->flags & ~permitted_flags) != 0)
>
On Wednesday 03 May 2006 17:31, Andrey Panin wrote:
> > What he
> > should do would be to create a moschip.c that uses usbnet as a support
> > module - just like asix.c does. In this file, he can have his sole
> > Copyright attribution and not have to worry about following
> > changes/updates to u
On Wed, 3 May 2006 10:45:14 -0700, Greg KH <[EMAIL PROTECTED]> wrote:
> On Wed, May 03, 2006 at 12:16:00AM -0700, Pete Zaitcev wrote:
> Should this also go into the -stable queue?
Yes, I think it meets criteria for -stable. It is a bug fix, is not
polluted with unrelated fixes, and is short (49 l
On Wed, May 03, 2006 at 12:16:00AM -0700, Pete Zaitcev wrote:
> In kernel 2.6.16, if a mounted storage device is removed, an oops happens
> because ub supplies an interface device (and kobject) to the block layer,
> but neglects to pin it. And apparently, the block layer expects its users
> to pin
Pete Zaitcev wrote:
This is not news. Just build ehci-hcd statically if your userland
is broken and outside of your control.
-- Pete
Alan Stern wrote:
Indeed. There's not much point in preventing people from removing the HCD
module when they can physically unplug the USB cable at any time
On Tue, 02 May 2006 16:27:12 -0700 Mark McClelland wrote:
> Randy.Dunlap wrote:
> > On Tue, 02 May 2006 12:47:20 -0700 Mark McClelland wrote:
> >
> >> Randy.Dunlap wrote:
> >>> I downloaded 2.32 and tested it on my ibot2. All that I see is a
> >>> kernel log message that says:
> >>> /home/rdunla
On Wed, May 03, 2006 at 11:04:19AM -0400, Alan Stern wrote:
> On Tue, 2 May 2006, Glenn Maynard wrote:
>
> > > So, why won't we simply encode the knowledge about things which
> > > are safe for ub in a monstrous if-if-if statement? I considered
> > > this, but found it a) not safe enough, b) clums
Can anybody point me to someone that can give me advice on this
Regards,
Leon
> Hi all,
>
> I am struggling with this beast to get it to (fully-)work under linux, this
> is what I have done:
>
> 1. Used usbsnoopy to get some raw zboard usb traffic.
> 2. Added #debug and #debug_data to hid-core.c
On 123, 05 03, 2006 at 10:44:48AM -0400, David Hollis wrote:
> On Wed, 2006-05-03 at 15:28 +0200, Michael Helmling wrote:
>
> > So, what this Mr. Srihdar di wrong is to set his own name in the
> > "copyright"
> > field instead of using yours. The process of modifying a GPLed module
> > itself
On Tue, 2 May 2006, Pete Zaitcev wrote:
> On Tue, 02 May 2006 17:36:09 -0700, Randy Vinson <[EMAIL PROTECTED]> wrote:
>
> > This problem was found while executing a "reboot" command with
> > a USB floppy drive or a USB hard drive mounted. The hotplug scripts
> > were unloading the ehci_hcd modu
On Tue, 2 May 2006, Glenn Maynard wrote:
> > So, why won't we simply encode the knowledge about things which
> > are safe for ub in a monstrous if-if-if statement? I considered
> > this, but found it a) not safe enough, b) clumsy, c) redundant.
>
> I guess it seems more clumsy and redundant to me
On Wed, 2006-05-03 at 15:28 +0200, Michael Helmling wrote:
> So, what this Mr. Srihdar di wrong is to set his own name in the "copyright"
> field instead of using yours. The process of modifying a GPLed module itself
> is ok, am I right with this?
> So it should be possible to convince him of th
On Wed, 3 May 2006, Olaf Hering wrote:
> On Wed, May 03, Olaf Hering wrote:
>
> > On Tue, May 02, Alan Stern wrote:
> >
> > > Are you certain this patch is responsible for the breakage? That is, did
> > > you build two kernels that differ only in whether or not this patch is
> > > included
On Wed, May 03, Olaf Hering wrote:
> On Tue, May 02, Alan Stern wrote:
>
> > Are you certain this patch is responsible for the breakage? That is, did
> > you build two kernels that differ only in whether or not this patch is
> > included and compare their behavior? (I don't trust the git-bi
On Wednesday 03 May 2006 07:29, David Brownell wrote:
> On Tuesday 02 May 2006 10:06 pm, Michael Helmling wrote:
>
> They just hacked "usbnet". There are huge chunks of code, and comments,
> that are clearly identical. At least half of the "moschip" driver.
>
Then what they did really isn't rig
On Wednesday 03 May 2006 07:29, David Brownell wrote:
> On Tuesday 02 May 2006 10:06 pm, Michael Helmling wrote:
>
> They just hacked "usbnet". There are huge chunks of code, and comments,
> that are clearly identical. At least half of the "moschip" driver.
>
Then what they did really isn't rig
On Tue, May 02, Alan Stern wrote:
> Are you certain this patch is responsible for the breakage? That is, did
> you build two kernels that differ only in whether or not this patch is
> included and compare their behavior? (I don't trust the git-bisect
> procedure to do this correctly.)
2.6.1
In kernel 2.6.16, if a mounted storage device is removed, an oops happens
because ub supplies an interface device (and kobject) to the block layer,
but neglects to pin it. And apparently, the block layer expects its users
to pin device structures.
The code in ub was broken this way for years. But
29 matches
Mail list logo
