Mail Archive Search: <+subject:/^(?:^\s*(re|sv|fwd|fw)[\[\]\d]*[:>-]+\s*)*Dealing\s+with\s+buggy\s+hardware\s+$was\:\s+b44\s+and\s+4g4g$\s*$/>

Results:

References: [ +subject:/^(?:^\s*(re|sv|fwd|fw)[\[\]\d]*[:>-]+\s*)*Dealing\s+with\s+buggy\s+hardware\s+$was\:\s+b44\s+and\s+4g4g$\s*$/: 16 ]

Total 16 documents matching your query.

1. Dealing with buggy hardware (was: b44 and 4g4g) (score: 1): Author: adi@xxxxxxxxxx>; Date: Sat, 5 Jun 2004 23:06:44 +0300; And here's a workaround-everything-in-the-driver version that makes everything work. Cc:d to linux-kernel to get wider coverage. There _really_ has to be a better way of dealing with hardware problem; /archives/netdev/2004-06/msg00106.html (13,280 bytes)
2. Re: Dealing with buggy hardware (was: b44 and 4g4g) (score: 1): Author: <pp@xxxxxxxxxx>; Date: Sat, 5 Jun 2004 13:19:23 -0700; You can't use this non-portable interface, you have to: 1) pci_map the data 2) test the dma_addr_t returned; /archives/netdev/2004-06/msg00107.html (8,476 bytes)
3. Re: Dealing with buggy hardware (was: b44 and 4g4g) (score: 1): Author: Oosterhout <kleptog@xxxxxxxxx>; Date: Wed, 9 Jun 2004 15:29:05 +0300; Ok, fixed. Certainly not ideal, but should fix things for those with problems (ie. running the 4G4G patch) and work as before for everyone else. -- linux-2.6.6-1.422/drivers/net/b44.h.4g4g 2004-06-09; /archives/netdev/2004-06/msg00244.html (13,885 bytes)
4. Re: Dealing with buggy hardware (was: b44 and 4g4g) (score: 1): Author: ipe Alfaro Solana <felipe_alfaro@xxxxxxxxxxxxx>; Date: Thu, 10 Jun 2004 23:34:42 +0300; Yikes! With the 4:4 VM split it definately is instantaneous with > 1GB of memory, I triggered it with 1.25G myself and never noticed anything wrong with just 1GB (allocation starts from the top it se; /archives/netdev/2004-06/msg00285.html (9,722 bytes)
5. Re: Dealing with buggy hardware (was: b44 and 4g4g) (score: 1): Author: xxxxxxxxxxxx>; Date: Thu, 10 Jun 2004 22:05:04 +0200; This should hit machines with 2GB ram too, right? Is it possible to find if it hits me? I get hard lockups on 2GB machine with b44, but they take ~5min.. few hours to reproduce... It seems to me lik; /archives/netdev/2004-06/msg00286.html (9,412 bytes)
6. Re: Dealing with buggy hardware (was: b44 and 4g4g) (score: 1): Author: x>; Date: Thu, 10 Jun 2004 23:12:17 +0200; Okay, this is probably other problem. When the bug hit, what are the symptoms? Can you try the driver from broadcom? bcom4400, or how is it called. Its extremely ugly, but might get this kind of stu; /archives/netdev/2004-06/msg00289.html (10,351 bytes)
7. Re: Dealing with buggy hardware (was: b44 and 4g4g) (score: 1): Author: xxxxxxxxx>; Date: Fri, 11 Jun 2004 09:17:30 +0300; Total immediate crash without an oops. When the RX ring skbufs are allocated with GFP_DMA receives work, but any transmits from > 1GB cause a link down/link up (which is just about all of them). With; /archives/netdev/2004-06/msg00303.html (9,842 bytes)
8. Re: Dealing with buggy hardware (was: b44 and 4g4g) (score: 1): Author: R. Rodriguez); Date: Fri, 11 Jun 2004 11:45:23 +0200; You might want to report them, then look at diff between latest and previous versions :-)))). Pavel -- People were complaining that M$ turns users into beta-testers... ...jr ghea gurz vagb qrirybcre; /archives/netdev/2004-06/msg00306.html (10,348 bytes)
9. Dealing with buggy hardware (was: b44 and 4g4g) (score: 1): Author: Pekka Pietikainen <pp@xxxxxxxxxx>; Date: Sat, 5 Jun 2004 23:06:44 +0300; And here's a workaround-everything-in-the-driver version that makes everything work. Cc:d to linux-kernel to get wider coverage. There _really_ has to be a better way of dealing with hardware problem; /archives/netdev/2004-06/msg00990.html (13,409 bytes)
10. Re: Dealing with buggy hardware (was: b44 and 4g4g) (score: 1): Author: "David S. Miller" <davem@xxxxxxxxxx>; Date: Sat, 5 Jun 2004 13:19:23 -0700; You can't use this non-portable interface, you have to: 1) pci_map the data 2) test the dma_addr_t returned; /archives/netdev/2004-06/msg00991.html (8,591 bytes)
11. Re: Dealing with buggy hardware (was: b44 and 4g4g) (score: 1): Author: Pekka Pietikainen <pp@xxxxxxxxxx>; Date: Wed, 9 Jun 2004 15:29:05 +0300; Ok, fixed. Certainly not ideal, but should fix things for those with problems (ie. running the 4G4G patch) and work as before for everyone else. -- linux-2.6.6-1.422/drivers/net/b44.h.4g4g 2004-06-09; /archives/netdev/2004-06/msg01128.html (14,045 bytes)
12. Re: Dealing with buggy hardware (was: b44 and 4g4g) (score: 1): Author: Pekka Pietikainen <pp@xxxxxxxxxx>; Date: Thu, 10 Jun 2004 23:34:42 +0300; Yikes! With the 4:4 VM split it definately is instantaneous with > 1GB of memory, I triggered it with 1.25G myself and never noticed anything wrong with just 1GB (allocation starts from the top it se; /archives/netdev/2004-06/msg01169.html (9,933 bytes)
13. Re: Dealing with buggy hardware (was: b44 and 4g4g) (score: 1): Author: Pavel Machek <pavel@xxxxxxx>; Date: Thu, 10 Jun 2004 22:05:04 +0200; Hi! This should hit machines with 2GB ram too, right? Is it possible to find if it hits me? I get hard lockups on 2GB machine with b44, but they take ~5min.. few hours to reproduce... It seems to me; /archives/netdev/2004-06/msg01170.html (9,595 bytes)
14. Re: Dealing with buggy hardware (was: b44 and 4g4g) (score: 1): Author: Pavel Machek <pavel@xxxxxx>; Date: Thu, 10 Jun 2004 23:12:17 +0200; Hi! Okay, this is probably other problem. When the bug hit, what are the symptoms? Can you try the driver from broadcom? bcom4400, or how is it called. Its extremely ugly, but might get this kind of; /archives/netdev/2004-06/msg01173.html (10,593 bytes)
15. Re: Dealing with buggy hardware (was: b44 and 4g4g) (score: 1): Author: Pekka Pietikainen <pp@xxxxxxxxxx>; Date: Fri, 11 Jun 2004 09:17:30 +0300; Total immediate crash without an oops. When the RX ring skbufs are allocated with GFP_DMA receives work, but any transmits from > 1GB cause a link down/link up (which is just about all of them). With; /archives/netdev/2004-06/msg01187.html (10,112 bytes)
16. Re: Dealing with buggy hardware (was: b44 and 4g4g) (score: 1): Author: Pavel Machek <pavel@xxxxxx>; Date: Fri, 11 Jun 2004 11:45:23 +0200; Hi! You might want to report them, then look at diff between latest and previous versions :-)))). Pavel -- People were complaining that M$ turns users into beta-testers... ...jr ghea gurz vagb qriryb; /archives/netdev/2004-06/msg01190.html (10,647 bytes)

Current List: 1 - 16
Page: [1]